[
Lists Home |
Date Index |
Thread Index
]
I have been automating transactions since 1979. For any particular transaction
type, I work myself (and those who work with me on the project) out of a job
in no more than a matter of weeks, or at most, months. We do not do ourselves
out of work, however, because there are always new strategies and (to use
Len's terms) new assemblies of parts which require new transaction processing.
Designing those new strategies and assemblies is the creative work which my
clients do. More than that it is the necessary, ongoing innovation which keeps
them competitive and in business. The clients cannot quit innovating in order
to immerse themselves in the drudgery of transaction processing, and
particularly not to work out the exception handling--that is what they hire me
for.
My goal is to provide a stable mechanism to handle each exception, ideally the
first time that I see it. Just as in Simon's examples, the volume of any new
transaction type is low because my client, and the counterparties with which
it executes each new type of transaction, are at first working out the
annoying details and exceptional cases of the transaction in the terms of
their business and its workflows, just as I have to work the analogous
problems out in processing the execution and settlement of those transactions.
Typically the first transaction of a new type will require full days of the
business principals on the telephone with their first counterparty to agree on
the details of a single execution, as well as conversations with legal counsel
as those details are agreed upon. Subsequent transactions build directly on
earlier experience--particularly experience with the exceptions--and go
through with increasing speed.
Better than twenty years' experience has taught me why none of the three
mechanisms you propose will work at all in the cases I am familiar with, let
alone get you "compatibility with every consumer on the planet". First, there
will be no standard formats for the transaction types I have to process at the
time I have to begin processing them. Designing those formats ad hoc is the
very heart of what I do. That design must embrace, or at least not preclude,
the practices of my client's counterparty with nearly as much priority as
those of my client, just so that the transaction can be successfully done with
that counterparty. The format must also quickly adapt to accommodate the next
counterparty, and the ones after that. The first transactions with each new
counterparty in the early days of a transaction type will predictably kick out
as exceptions, which is the price of the learning curve that is necessary to
bring in the business of those counterparties. Later, when the transaction
type is established and familiar to potential counterparties, newcomers will
either ask to have a data format specified to them or will specify the one
that they are already standardized on and expect to use. In the early days,
however, they will deliver transaction data in whatever form they can get it
produced, either from systems of their own which they a building, expanding,
or adapting to accommodate the new transaction type, or from what is available
to them from clearing correspondents or others on whom they depend for
services.
Second, the webform is infeasible except for the very smallest participants
and will be refused by the counterparties on which my client depends to take
the other side of these transactions. Those counterparties have systems of
their own, which they are expanding and adapting to handle the new transaction
type. They will expect to use the output of those systems as input to my
client, and vice versa, and will not consent to the de-automation of someone
re-typing data from those systems into a webform on an ongoing basis.
Finally, the transmission of non-electronic data, as faxes or even voice
telephone calls, does not scale and is infeasible except for correcting the
exceptions when they are encountered, and when a human must examine the
specific case.
Respectfully,
Walter Perry
Paul Prescod wrote:
> Here is how I would structure purchasing at a business I would own:
>
> 1. Accept XML in all of the most popular purchasing formats: ebxml 2,
> biztalk 3000, etc. etc.
>
> 2. Supply a web form for those who cannot generate standardized XML.
>
> 3. Supply phone and fax numbers for those who cannot use the web.
>
> That would buy me compatibility with every consumer on the planet
> without forcing non-programmers to become variant XML de-cryptogrophers.
> If a human being on my side needs to be involved anyhow then it is not
> clear what value I'm getting out of XML for that transaction. Why not
> have the customer use the Web form?
[snip]
> Variety is perfect for systems managed by humans. Conformity is better
> for systems managed by computers. Having computers "kick out" bad
> documents and forcing humans deal with them is what is broken. It puts
> the human at the mercy of the system and shifts the burden of generating
> appropriate data from the producer, where it should lie, to the
> consumer, where it should not. If you provide the producer with easy
> ways to generate proper data (e.g. a web form) then why wouldn't they
> conform?
|
