Cart
[Home] [By Thread] [By Date] [Recent Entries]
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?
|
