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

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

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>
>