RE: Units of Measure; mechanics of adoption

[Todd Boyle <tboyle@rosehill.net>]

Arofan said,

  ...receive an XML document over the wire, and use a simple application
  to present the document as a web form that they would respond to. The web
  form is nothing more than an XSL style sheet, with some forms controls
  embedded for sending back an acceptance of the order, for example.

  A similar program would take XML, present a "blank" PO (as described at
  run-time by schema or DTD) and present it in a browser for Order
  creation using XSL to represent it as a form....

Yes!  Lightweight. Low cost.

Stephanie said (among many worthy ideas)

  ...however, I do have a gut feeling that machines are going to do most
  of the reading, so if we have make a tradeoff I'd advocate a solution
  that is slightly less person-friendly in order to make it less likely
  to be misinterpreted by a machine.

Well, be sure to crank this into your model too: trust is the #1 problem
in moving small business adoption.  There is a broad segment
from the clerical level right up to the controller and the outside
accountants, who continue to distrust internet commerce.

We need fast adoption like at least 1M, 2M small businesses in the first
couple of years, or we're dead.  We need to gain a foothold among all
the proprietary systems before they all become interconnected with
middleware and ad-hoc solutions.

Adoption is often decided by older people, business owners, bookkeepers,
who are not the geeks in the company.  They will be more comfortable if
they can "read" the source documents to some extent.

When some lowly clerk prints the source XML doc and finds out they can
read it, the senior people will damn well read it too, or lose some
turf.   The clerk is going to ask "Why are you blocking me from
using these automatic downloads?"  The clerks are the big winners
from much of this automation and they won't have any XML tools at
first.  But clerks do have their notepad.

By the way, clerks and accountants in small business OWN the data. You
HAVE to reckon with them, one by one.  There isn't anybody else in the
equation, who is going to force them to conduct business over the
internet, with ebXML.  Owners and managers in small business do *not*
micro-manage their clerks and accountants, choosing instead to
underpay them.  But it is extremely disruptive when they quit.

Back to the trust issue--there is no player, among the IT or systems
professionals serving a small business, who can "audit" an internet
commerce system, cost effectively, today.  But there are millions of
accountants in the US with some periods of audit training and
experience.  There are around 500,000 CPAs.  They have reputation,
credibility and skills in tests of transactions and internal control.
It should be a high priority to make ebXML straightforward enough
to satisfy this group, out of the box.

At ASPs and BSPs and every other "stewardship" scenario, there are also
individuals in controlling roles.  These are not SEs--they are the
business process people.  HR people, CRM and inventory and support
people -and their own internal auditors. These people are managing
the execution of large volumes of transactions with 3rd parties on
behalf of their subscribers.  None of us are SGML or EDI geeks.

ebXML must be designed to sell, to be appealing and satisfying to all of
these people, as if their opinion truly matters.  They are absolutely,
totally busy. If they cannot immediately understand ebXML they have only
one other choice: hire somebody who is experienced in ebXML in their
city or town


One model for ebXML in SMEs will be that arriving ebXML docs are
totally untrusted like postal mail.  They will arrive in the inbox or
unposted transaction batches until reviewed and approved by humans.
Users will certainly inspect what's in their outbox.

Another case that will be very common is the broken XML file. A lot of
time will be saved if people can fix some tags or data with notepad.
There are hundreds of scenarios you will win, and few that you lose, by
making the ebXML payload human readable.  I certainly hope Core
components can be designed to be machine-readable as well as
human-readable :-)

In case the "syntax neutral" corpse is still twitching, let me state
that scrambling the tags into pig latin, so they won't mean anything,
is the nuttiest idea I ever heard,

* Todd F. Boyle CPA    http://www.GLDialtone.com/
* tboyle@rosehill.net    Kirkland WA    (425) 827-3107
* XML accounting, web ledgers, BSPs, ASPs, whatever it takes