[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [legalxml-econtracts] Automated Negotiation Scenario
|
Folks, As
we discussed at the last conference call, here is a scenario for automated
negotiation. The scenario itself is quite general, along with a more specific
example to (hopefully) make the points somewhat clearer. I
am considering this a working document and look forward to comments from the
group. Best, Dave
Marvit Fujitsu
Labs Scenario
Document
Owner: Dave Marvit, Version:
1.0 Date: Introduction This
document is a scenario developed as part of the eContracts requirements
process. The goal is to describe a generalized automated negotiation process
and determine the minimal set of requirements for an eContract specification
that will support such a process. Stakeholders The
stakeholders for an automated negotiation system are parties that will be
engaging in transactions in which the space of business terms (parameter space)
is both well understood and rich. These will typically be commodity
transactions. Scenario
Statement Regular
business partners are engaging in an automated transaction of some commodity.
They recognize that there are many business terms (call them parameters) in
each such deal relating to, for example, delivery and payment schedules, price
(which constantly fluctuates in this commodity market), and the details of the
specification of the commodity. The
parties recognize that in any given transaction one side might care a lot about
one parameter such as delivery date, while this may be much less important to
the other side which may be more concerned about, say, the quality of the goods
shipped. In such a rich parameter space in which the parties have differing
(but competing) value functions, all parties want to automate the negotiation.
Here negotiation is defined as process of making tradeoffs between parameters
as a part of the process of reaching an agreement. An automated system exchanges documents
thereby exploring this complex parameter space until an agreement is reached or
the process is abandoned. If an agreement is reached, an eContract is generated
and, once approved, is signed electronically by the parties. After
the contract is signed it moves on to other systems that are beyond the scope
of this scenario Example A
PC manufacturer is in need of memory chips for a new batch of PCs. The chip
manufacturer can provide a variety of types of chip (RDRAM, SDRAM and so on),
many sizes, speeds, reliability levels and so on. The provider can deliver
these chips along many different timelines. And, of course, the price will vary
depending upon the exact combination of all of these terms. The
importance that the manufacturer places on each of these different terms (chip
type, chip size, delivery schedule, and so on) depends on a variety of factors,
including orders in the queue, support resources, current debt load,
predictions of coming price reductions in memory costs, the economic viability
of the chip vendor, and a variety of other internal and external conditions.
Determining how much importance to place on each term is a complex process
that, for the sake of argument, we will assume exists. The mathematical
expression of the importance of each business term (or parameter) is called a
'value function'. The
chip manufacturer has a value function as well, although the specific
importance that the seller places on each term is quite different from the
buyer's. It is this difference in value functions that allows both parties to
benefit from the transaction. Every
good negotiator knows that you can often find a deal that
benefits both sides by adding more business terms into the mix. "If
you can wait a week longer for that I can save some money and share the savings
with you." Here there is a tradeoff between time and money that benefits
both sides. As more parameters are added the opportunity for savings increases.
("Do you really need such a fast chip? I can get you a bigger slower chip
for the same price" and so on.)With the rich parameter set described in
the memory chip example the opportunities for savings are considerable (mathematical) space of possibilities. Unfortunately,
as the richness of the parameter space increases, so does the complexity.
Humans have difficulty handling negotiations with many parameters. They
certainly cannot process such negotiations in a timely fashion. Hence the need for automated negotiation. In
the automated negotiation, the manufacturer and the chip vendor exchange
documents that describe different proposed values for the different business
terms. They iterate as they (hopefully) zero in on a deal that maximized the
total value. All of this takes place in the context of their competing
interests. Once
a set of terms is reached that is agreeable to both sides a formalization of
that agreement takes place, here by generating an eContract and applying
digital signatures. Summary
of Key Benefits to Stakeholders 1.
The capability of exploring a rich parameter space (a rich set of business
terms) automatically allows all parties to extract more value from each
transaction. (An automated negotiation system can explore a much richer
parameter space than humans ever could, and it can explore such a space more
exhaustively. This allows discovery of those points where each side's needs can
be met at a minimal cost to the other.) 2. Negotiating a contract in this
manner can significantly reduce time and costs associated with the transaction
process. 3. Lowering the costs associated with transactions makes many types of
transactions economically feasible that are not feasible in a manually
negotiated context. Assumptions 1.
Enough business terms can be represented as negotiable 'parameters' that such a
system can be useful. This does not require that ALL business terms can be
parameterized, nor does it presume that it is practical to represent all
business terms as parameters. 2. This approach does not need to benefit all
forms of contract negotiations to still have significant utility. 3. The
process of assigning 'value' to each of the different parameters is out of
scope for this discussion. 4. Documents other than the contract will be
exchanged in the process of negotiation. 5. Documents other than the
parameterized business terms may be required to generate the contract, such as
documents containing formatting information. Requirements 1.
Business terms must be represented such that their values can be changed independently
of one another. 2. An eContracts can be generated by a list of parameterized
business terms (and possibly non 3.
The point at which contracts are agreed to by the parties involved must be made
clear to all involved. Non There
does not need to be any mechanism within the contract itself for representing
whether a term is negotiable or not. Notes The
actual process of negotiation will take place through the exchange of abstract
representations of the contract terms specifically designed for the negotiation
process. The eContracts itself will not be the format used for all of these
exchanges. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC