Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...

[David Lyon <david.lyon@globaltradedesk.com>]

Hi Mike,

So you're trying to tell me that ebXML could never run on the following
hardware:

http://www.diamondsystems.com/products/prometheus

or

http://www.rabbitsemiconductor.com/products/rcm2200/index.html

Is there some sort of incompatability ? or something that I don't know
about.

These devices already run web servers quite fine so I'm interested to know
why ebXML couldn't be tacked on them as well.

David

----- Original Message -----
From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
To: <ebxml-dev@lists.ebxml.org>
Sent: Tuesday, April 23, 2002 11:40 PM
Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...


> David,
>
> While we agree about SME requirements, I think your remedy is a bit on
> the edge of fantasy.  ebXML on a chip?   This reminds me of when people
> were afraid that Microsoft was going to build EDI into Windoze.   I can
> see an XML parser on a chip a lot sooner than ebXML, and I don't expect
> to see a W3C schema validating parser on a chip any time soon.   We
> don't even have fully compliant parsers in software yet!
>
> Get real ;^)
>
> Mike
>
> David Lyon wrote:
>
> >Mike,
> >
> >You're absolutely right.
> >
> >>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.
> >>
> >
> >That's why I say that somebody has to go to Asia and produce ebXML on a
> >chip.
> >
> >SMEs will be able to then afford the product. And you will be able to get
an
> >ROI providing that you can make it work.
> >
> >David Lyon
> >Product Manager
> >www.globaltradedesk.com
> >
> >
> >----- 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>;
> ><ebxml-dev@lists.ebxml.org>
> >Sent: Tuesday, April 23, 2002 5:15 AM
> >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...
> >>
> >>Christopher Harvey wrote:
> >>
> >>>Rachel,
> >>>
> >>>>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.
> >>>>
> >>>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.
> >>>
> >>>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"?
> >>>
> >>>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.
> >>>
> >>>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.
> >>>
> >>>Regards
> >>>Chris Harvey
> >>>Zara Technology Pte Ltd
> >>>Singapore
> >>>
> >>>----- Original Message -----
> >>>From: "Rachel Foerster" <rachelf@ix.netcom.com>
> >>>To: "'Christopher Harvey'" <ckharvey@zaratechnology.com.sg>; "'Todd
> >>>
> >Boyle'"
> >
> >>><tboyle@rosehill.net>
> >>>Cc: <ebxml-dev@lists.ebxml.org>
> >>>Sent: 23 April 2002 01:17
> >>>Subject: RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
...
> >>>
> >>>
> >>>>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.
> >>>>
> >>>>Rachel
> >>>>
> >>>>-----Original Message-----
> >>>>From: Christopher Harvey [mailto:ckharvey@zaratechnology.com.sg]
> >>>>Sent: Sunday, April 21, 2002 9:09 PM
> >>>>To: Todd Boyle
> >>>>Cc: ebxml-dev@lists.ebxml.org
> >>>>Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
> >>>>...
> >>>>
> >>>>
> >>>>Todd,
> >>>>
> >>>>Extremely well put. It's somehow comforting to know that SMEs in the
US
> >>>>
> >>>have
> >>>
> >>>>the same 'mentality' as SMEs here in Asia.
> >>>>
> >>>>The big gap to be bridged is in getting SMEs to understand that there
is
> >>>>
> >a
> >
> >>>>direct financial benefit to be had; opposing that is their belief that
> >>>>
> >>>their
> >>>
> >>>>data must remain 'secret' (as it had for generations - a necessity
when
> >>>>
> >>>more
> >>>
> >>>>than one set of books have been historically kept).
> >>>>
> >>>>Rachel is absolutely correct when she says: It's a business imperative
> >>>>
> >and
> >
> >>>>necessary now and into the future to be able to exchange unambiguous
> >>>>
> >data.
> >
> >>>>As a tech company, we know that. Our government knows that. But
getting
> >>>>
> >>>SMEs
> >>>
> >>>>to understand that is a whole different uphill struggle.
> >>>>
> >>>>ebXML is an excellent initiative but... the real SMEs, the mass-market
> >>>>
> >>>small
> >>>
> >>>>ones, with 50 or usually less, employees - which make up the vast
> >>>>
> >majority
> >
> >>>>of companies - have a mindset that you would not believe unless you
have
> >>>>been exposed to it. For the success of ebXML, and e-commerce in
general,
> >>>>
> >>>it
> >>>
> >>>>is imperative that all involved with these important initiatives have
a
> >>>>
> >>>good
> >>>
> >>>>grasp of the SME mindset.
> >>>>
> >>>>I hope this is not drifting off topic but it is vital that XML
potential
> >>>>does not become solely the domain of the big players...
> >>>>
> >>>>Regards
> >>>>Chris Harvey
> >>>>Zara Technology Pte Ltd
> >>>>Singapore
> >>>>
> >>>>
> >>>>----- Original Message -----
> >>>>From: "Todd Boyle" <tboyle@rosehill.net>
> >>>>To: <rachelf@ix.netcom.com>
> >>>>Cc: <ebxml-dev@lists.ebxml.org>
> >>>>Sent: 22 April 2002 07:56
> >>>>Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
> >>>>
> >...
> >
> >>>>
> >>>>>At 09:36 AM 4/21/02, Rachel Foerster wrote:
> >>>>>
> >>>>>>It's a business imperative and necessary now and into the future
> >>>>>>to be able to exchange unambiguous data. And personally I believe
the
> >>>>>>future will be **not** the shipping off to a business partner data
or
> >>>>>>documents, etc. but providing real time controlled access to the
> >>>>>>
> >>>>necessary
> >>>>
> >>>>>>information transparently between enterprises so that
cross-enterprise
> >>>>>>business processes can execute to the desired outcome.
> >>>>>>
> >>>>>As more and more small businesses have always-on connections
> >>>>>to the internet, sooner or later it will dawn on them to expose at
> >>>>>least some limited views or query interfaces to their customers
> >>>>>and suppliers.
> >>>>>
> >>>>>Small businesses often have only one person performing all roles
> >>>>>that interface a particular customer or supplier, and accordingly
> >>>>>have no need for business process management. The cost of updating
> >>>>>all the statuses and stages of a BP exceed their benefit.  Cell
phones,
> >>>>>headsets, and the collapse of long distance have made it even cheaper
> >>>>>to handle exceptions.
> >>>>>
> >>>>>I don't wish to diminish the usefulness of ebXML BP in any way, for
> >>>>>Enterprise or other value chains where they are appropriate!  But
> >>>>>I think the exchange of documents remains the best potential
> >>>>>way to get ebXML in the door of SMEs.  And, once they gain some
> >>>>>familiarity with it, they will be much closer to supply chain
> >>>>>
> >>>integration
> >>>
> >>>>>or other BP scenarios.  Here is one fictitious dialog for
> >>>>>your entertainment
> >>>>>
> >>>>>Todd Boyle CPA
> >>>>>AR/AP everywhere  www.arapxml.net
> >>>>>
> >>>>>Let's take a break, and get beat up by a small busieness owner....
> >>>>>
> >>>>>Q:  "Why should I allow my customer or supplier to see the purchase
> >>>>>and sale data in *my* accounting system?? "
> >>>>>
> >>>>>A: "you already do.  Whenever you send a PO or an invoice. "
> >>>>>
> >>>>>Q:  Yeah but why should I allow them to see their Account Receivable
> >>>>>page, or Account Payable, in *my* system?
> >>>>>
> >>>>>A:  You already do, whenever you send them a statement.
> >>>>>
> >>>>>Q.  Yeah, but I never send statements until they have been reviewed
> >>>>>at the end of the month and the bank account is reconciled to find
> >>>>>all the mistakes in our posting payments.
> >>>>>
> >>>>>A.  Ok then why don't you expose a view of the invoices now,
> >>>>>and expose the reviewed statements at the end of the month?
> >>>>>You don't have to change your procedures at all.  Too bad your bank
> >>>>>is so unhelpful http://www.gldialtone.com/transaction04.htm
> >>>>>
> >>>>>Q.  Well why should I do this, what's the payoff for me?
> >>>>>
> >>>>>A.  Some of your customers might pay you sooner.
> >>>>>
> >>>>>Q.  Yeah but all my good customers already pay me on time,
> >>>>>and my bad customers, I don't think they have the intelligence
> >>>>>to use a computer.
> >>>>>
> >>>>>A.  Maybe when they can login and see their account they will
> >>>>>understand it better.  Maybe they are paying their other suppliers
> >>>>>sooner than they are paying you. Why don't you try emailing them
> >>>>>their statements more often.
> >>>>>
> >>>>>Q.  Yeah but what are you trying to sell me?  You're just trying
> >>>>>to capture me into a central server or single-vendor software.
> >>>>>
> >>>>>A.  Sharing views *directly* with trading partners is the exact
> >>>>>opposite of being trapped in a portal model.  Today, you are
> >>>>>trapped in two separate portal models:  first, you are trapped in
> >>>>>your local software with no electronic interface...
> >>>>>
> >>>>>Q.  Yeah but what am I supposed to "Interface" with?  There is
> >>>>>no standard. Nobody else has any "Interface" either.
> >>>>>
> >>>>>A.  Do you vote?
> >>>>>Q.  Yes.
> >>>>>A.  Do you make charitable contributions?
> >>>>>Q.  Yes.
> >>>>>A.  How much did you contribute last year?
> >>>>>Q.  None of your business.
> >>>>>A.  Transaction integration helps the planet and it doesn't
> >>>>>         cost you anything.
> >>>>>
> >>>>>Q.  What do you mean??
> >>>>>
> >>>>>A.  You're cutting down the paper consumption, getting
> >>>>>vehicles off the road, cutting trips to banks and post offices.
> >>>>>You're saving labor. People can do more useful things.
> >>>>>
> >>>>>Q.  Yeah but what do you mean, "Free"?
> >>>>>
> >>>>>A.  Do you already do accounting work, posting all your sales
> >>>>>and purchases?
> >>>>>
> >>>>>Q.  Yes.
> >>>>>
> >>>>>A.  Then exposing the data to the trading partner costs effectively
> >>>>>nothing. You don't have to compose any new documents. In fact,
> >>>>>the trading partner can freeload off your data entry work.  They
> >>>>>simply click "OK" to suck your data into their computer and post it.
> >>>>>
> >>>>>Q.  Yes.  But where is the software to do this??
> >>>>>
> >>>>>A. There are modules in the open source ebXML projects, and in
> >>>>>the VARs and developer communities of most of the accounting
> >>>>>platforms.
> >>>>>
> >>>>>Q.  Why that's ridiculous.  You're bullsh*itting me.   Integration
> >>>>>always costs megabucks.   I have been burned many times in
> >>>>>the past by computer consultants.
> >>>>>
> >>>>>A.  In the past, the N-squared problem required a separate
> >>>>>software solution for every combination of thousands of software
> >>>>>products, that is, *millions* of adapters to connect with each other.
> >>>>>Since ebXML is a common format, each accounting platform only
> >>>>>needs one adapter.
> >>>>>
> >>>>>Q.  Well, I don't believe you.   Anyway, you said I am already
> >>>>>locked into  *two* different portal traps. What's the other one?
> >>>>>
> >>>>>A. You are trapped in the banking system with no other way to
> >>>>>settle ARs or APs except by running payments through banks
> >>>>>for each and every payment.  That wrecks your bookkeeping and
> >>>>>your trading partner's bookkeeping, since banks only process
> >>>>>payment data and block all the transaction data between small
> >>>>>businesses.
> >>>>>
> >>>>>Q.  That's right.  So, what good is AR/AP integration between me
> >>>>>and my trading partner?
> >>>>>
> >>>>>A.  Settlement intermediaries such as accounts receivable factors
> >>>>>can't be cheap today because the data is so confused.  But even
> >>>>>a robot can do settlement if data is good.  And if collateralized.
> >>>>>What you are doing is uncoupling the interest cost and the risk,
> >>>>>which cannot be avoided.  You are making the mechanics of accounting
> >>>>>and settlement cheaper.
> >>>>>
> >>>>>Derivatives, promissory notes or digital cash become more practical,
> >>>>>when you have high quality data.  Do you think global corporations
> >>>>>all write checks or bank transfers to each other?  at the end of
> >>>>>each month?  Not.
> >>>>>
> >>>>>Q.  OK you're telling me to provide a SOAP interface on my ARs
> >>>>>to my customers, and my APs to my suppliers???
> >>>>>
> >>>>>A.  Yes.
> >>>>>
> >>>>>Q.   Go away.  That's just not the way we do business in podunk.
> >>>>>
> >>>>>A.  Ok tell you what.   Why don't you pass me your ARs and APs
> >>>>>in UBL, in ebXML core components format, every time you do a
> >>>>>purchase or a sale.   You show me how much it's costing you,
> >>>>>screwing around with AR and AP, your banking and bank
> >>>>>reconcilation, and other settlement after the conclusion of a sale.
> >>>>>I will manage the ARs and APs and bank balances for you for 1/2
> >>>>>cost.  I will bounce all the business differences back to you, since
> >>>>>you're the only one who can resolve them anyway.
> >>>>>
> >>>>>Q.  Ok.   Deal.
> >>>>>
> >>>>>A.  Ok then why don't you let the computers connect, and do it
> >>>>>for nothing?  You realize, in the long run, I'm going to be charging
> >>>>>you money for operating a robot software I got from ebXML
> >>>>>open source?    sheesh...
> >>>>>
> >>>>>Todd Boyle CPA  9745-128th Ave NE  Kirkland WA
> >>>>>International Accounting Services, LLC  www.gldialtone.com
> >>>>>425-827-3107  AR/AP everywhere  www.arapxml.net
> >>>>>
> >>>>>
> >>>>>
> >>>>>----------------------------------------------------------------
> >>>>>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>
> >>>>>
> >>>>----------------------------------------------------------------
> >>>>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>
> >>>>
> >>>
> >>>----------------------------------------------------------------
> >>>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>
> >>>
> >>>
> >>--
> >>Michael C. Rawlins, Rawlins EC Consulting
> >>www.rawlinsecconsulting.com
> >>
> >>
> >>
> >>
> >>
> >>----------------------------------------------------------------
> >>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>
> >>
> >
> >
>
> --
> Michael C. Rawlins, Rawlins EC Consulting
> www.rawlinsecconsulting.com
>
>
>
>
>
> ----------------------------------------------------------------
> 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>
>