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

[Mike Rawlins <mike@rawlinsecconsulting.com>]

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