[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 ...
Chris, you may be right. On the other hand, ebXML, XML, nor any of its
friends and relations, is a silver/magic bullet.
If you haven't done so yet, take a look at the recent GAO report to the
Senate about the use of XML within the government. Now....extrapolate the
challenges, issues, and requirements set forth in that document to every
other enterprise a unit of the federal government may do business with, and
it ain't gonna be a easy road to travel....but travel it we must.
BTW, I no longer have the URL pointing to the GAO report. I trust one of you
still does and can re-post it.
Rachel
-----Original Message-----
From: Chris Webster [mailto:cwebster@caci.com]
Sent: Monday, April 22, 2002 2:45 PM
To: chris@optiserv.com
Cc: 'Christopher Harvey'; dave@officemate.net;
ebxml-dev@lists.ebxml.org; EMuzy@visionweb.com; hkmast@emrlogic.com;
jvitkus@visionweb.com; Ken Wood; nrai@first-insight.com;
rachelf@ix.netcom.com; Hom, Richard ; robert.shanbaum@gerbercoburn.com;
Scott Bussinger; 'Todd Boyle'
Subject: RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
...
I am new to this dialog. My name is Chris Webster and I work for CACI
International. I am also the functional architect of a procurement system
we are building, and we have struggled with EDI abnormalities and anomolies
for 5 years with previous versions of our system, and arrived at the
conclusion that eb-XML is more flexible, less expensive, easier to write,
and more adaptable to business processes which involve interoperability
than EDI is capable of being. If you consider the expense and aggrivation
of EDI translators and the specific EDI syntax needed to accomplish b-to-b
transactions, the small business community can clearly benefit from eb-xml
more than from EDI. So for the healthcare providers I cannot specifically
comment, but for the procurement community (particularly Federal) at-large,
eb-XML offers a great deal of promise for supply chain relationships which
will need less maintenance and more felxibility about business rules.
Thanks// Cw
"Christopher
J. Feahr, OD" To: rachelf@ix.netcom.com,
"'Christopher Harvey'"
<chris@optiser <ckharvey@zaratechnology.com.sg>,
"'Todd Boyle'" <tboyle@rosehill.net>
v.com> cc: ebxml-dev@lists.ebxml.org,
robert.shanbaum@gerbercoburn.com, Ken
Wood <ken.wood@worldnet.att.net>,
EMuzy@visionweb.com,
04/22/2002 jvitkus@visionweb.com,
hkmast@emrlogic.com, dave@officemate.net, Scott
03:29 PM Bussinger <scottb@opto-pps.com>,
nrai@first-insight.com, "Hom, Richard "
<Richard.Hom@netapp.com>
Subject: RE: [ebxml-dev] RE:
[EDI-L] Article on ebXML Core Components
...
Rachel,
(I just started following this listserve...)
I understand and agree strongly with your and Todd's comments, and with the
need for this message to get to the people writing business software for
small healthcare providers. Given the fragmentation within this particular
vendor community, however, and its limited experience with even classic
EDI, how do we get the "ebXML message" to them... including the specific
migration path from the classic EDI model? Some in the vision care
industry (an especially complex and fragmented "backwater" of healthcare)
have suggested that a large "clearinghouse-type" entity will simply "blow
past" the current vendors of provider desktop systems... with some sort of
"global services play" or a centralized, ASP-model physician office system
for managing insurance payor and supply chain relationships.
While such a play seems inevitable in some ways, it glosses over the
importance of tens of thousands of existing "marriages" between doctors and
hundreds of small software vendors. In any "troubled marriage", I think it
is ALWAYS prudent to take a hard look at the existing relationship and see
if it can be improved before bailing to the expensive and stressful option
of forging a new (and, in this case, radically different-looking)
relationship. Would a little "ebXML counseling" and some good middle-ware
give these folks a fighting chance? Most Office Management System vendors
who are following the HIPAA requirements are moving toward increased
standardization of the "electronic medical record", and are considering or
implementing major system changes around HIPAA anyway. They already have
tech support infrastructures and solid relationships with the
doctors. ebXML would seem to be an excellent opportunity for the more
visionary vendors to "spice up" those relationships and truly distinguish
themselves from their "less connected" competitors.
We just need to light the fire somehow. I believe the DOCTOR is the key to
achieving this in healthcare, and that healthcare (with the feds beating us
over the head) might be the best target industry for a coordinated ebXML
marketing/awareness campaign. I'll go a bit farther out on this limb...
the vision/optical industry, with its massive supply-chain requirements
(peripherally involved and overlapping with HIPAA requirements) might be
the very best segment of healthcare at which to target an initial ebXML
marketing effort. Vision/Optical industry is a nearly "blank slate" for
EDI... a rare thing these days!
Regards,
Christopher Feahr, OD
http://VisionDataStandard.org
At 12:17 PM 4/22/02 -0500, Rachel Foerster 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.
>
>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
> >
Christopher J. Feahr, OD
http://visiondatastandard.org
chris@optiserv.com
Cell/Pager: 707-529-2268
----------------------------------------------------------------
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC