RE: Economic relationships in business collaborations (long)

[Krishna Sankar <ksankar@cisco.com>]

Bob,
	Thanks for the long e-mail. Keep going, no problems. This is how we all get
to learn other stuff going on and true to our charter, we should be
leveraging and embracing all the work out there.

	You are right, the e-mail and the materials will take sometime to digest,
but that is fine. Again, we should not be re-inventing any work already out
there.

	cheers
-----Original Message-----
From: Bob Haugen [mailto:linkage@interaccess.com]
Sent: Wednesday, November 01, 2000 3:07 PM
To: 'ebXML-CCBP-Analysis (E-mail)'; Ebxml-Bp (E-mail)
Cc: 'Stefano POGLIANI'; William McCarthy (E-mail)
Subject: Economic relationships in business collaborations (long)


Warning: this is a long message and may require some study.
It is my summary of a series of conversations on ebXML mailing
lists, off-list emails, and ebXML metamodel and analysis work group
conference calls.  I think the contents are critical for understanding
business collaborations from a business (not technical) viewpoint.

_Short version: _

The ebXML metamodel defined commercial transaction
patterns, that is, simple exchanges of business documents
such as offer-acceptance, query-response, etc.  These
patterns greatly simplify the development of business
process models.

Business collaborations consisting of many related commercial
transactions also fall into patterns: for example, contract negotiations
or order-fulfillment.

Many if not most business collaboration patterns have to do with
trade, or exchanges of resources between trading partners:
for example, I give you a product or service, and take from you
cash in return.

There are a set of common semantic relationships among
commercial transactions that characterize trading collaborations.
Those common relationships have been analyzed for 20 years by
Professor William McCarthy of Michigan State University,
a member of the ebXML Business Process work group.  They are
embedded in the ebXML Collaboration Modeling Metamodel
as the Economic Elements.  See for example Figure 7.

http://www.ebxml.org/project_teams/business_process/wip/index.html#BPDoc
(watch for word wrap)

An understanding of Figure 7 and its surrounding text
will help to develop reusable models of the common trading
collaboration patterns, and also make the software to manage
trading collaborations easier to use from a business perspective,
because the common business semantics will be built in.

In this message and further work after Tokyo, I will define
some common trading collaboration patterns in terms
of the ebXML metamodel economic elements.  Since
there are some details of the metamodel that are still
in flux, so will be some of this work.

_More detail_

A story was told on a recent ebXML Analysis work group
conference call about the many uses and abuses of Advanced
Shipping Notice (ASN) business documents.  In one case, the
ASN was used not to notify of a shipment, but to notify the
customer that the goods were available for pickup.  In some
other cases, some other document might be used for the
same purpose.  So if the document doesn't necessarily
tell us what it means, what does?

I heard another related story about the various documents
or events that signify authorization for payment for components
in automotive supply chains:  pay on ASN, pay on receipt, pay
on issue, pay on production, pay on invoice, etc.

These are examples of economic relationships among commercial
transactions (or economic relationships among business documents,
if you want to think of it that way).

The economic relationships among commercial transactions can
be be reduced to a very simple model called REA (Resources,
Events and Agents).

http://www.reamodel.org/

Those are the concepts behind Figure 7 in the ebXML metamodel.
Some of the words in Figure 7 may seem strange - too abstract -
and may make the whole thing seem more complicated than it is
by means of unfamiliarity.  But the number of ideas is minimal.
I will try to simplify after introducing the key terms and definitions
from the current metamodel.  I apologize in advance for any
deficiencies in simplicity.  Bill McCarthy does a skit with Elmo
and Cookie Monster muppets that is much more effective, but
difficult to convey in text. Those of you who have seen the skit
can keep it in mind.


_Key concepts_

An Economic Resource is a quantity of something of value that is
under the control of an enterprise, which is transferred from one
partner type to another in economic events. Examples are cash,
inventory, labor service and machine service.

An Economic Event is the transfer of control of an Economic Resource
from one partner type to another partner type. Examples would include
sale, cash-payment, shipment, and lease.

(Not from the metamodel:)
An Economic Agent is the same as a Party, Partner or Partner Type,
depending on which ebXML document you are looking at.

Two other concepts are required to understand the economic
relationships:

Economic Commitment
An economic commitment is an obligation to perform an economic event
(that is, transfer ownership of a specified quantity of a specified economic
resource type) at some future point in time. Order line items are examples
of commitments.

EconomicContract
A contract is subtype of agreement between partner types that some actual
economic exchanges will occur in the future. Contracts can have recursive
relationships with other contracts, for example, yearly contracts with
monthly
releases and weekly or daily shipping schedules. Contracts are containers
for
collections of commitments. For example, a purchase order is a contract
wherein
the line items are commitments.

_Key economic relationships_

Fulfills
An economic event may fulfill a prior commitment.

Reciprocity
Reciprocity is a mandatory relationship between two or more commitments.
Commercial contracts require reciprocal commitments, called "consideration".

Duality
Duality is a relationship between Economic Events, where one is the legal or
economic consideration of the other. Examples include a payment for a
product
or service. If one economic event occurs, but its dual or expected
consideration
has not occurred, the giving partner type has an imputed claim against the
taking
partner type for the value of the economic resources transferred.


_Common patterns_

*Order-Fulfillment

This is certainly the most common trading collaboration pattern.

Orders are kinds of Economic Contracts.  Order line items are
Economic Commitments usually to deliver products or services
in exchange for money.

Orders may be formed by simple offer-acceptance commercial
transactions or contract negotiation patterns (see below).

Fulfillment means to execute Economic Events that fulfill the
commitments. For example, actually delivering the products
or services and paying for them.

The business collaboration model will define which event is
supposed to come first:  delivery or payment.  So the pattern
could be Order-Delivery-Payment or Order-Payment-Delivery.

Which ever event comes first, it establishes a claim (the Duality
relationship) for the fulfillment of the reciprocal commitment,
either payment or delivery.

The fulfillment event is obliged to match the commitment in terms
of quality, quantity and timing.  There could be terms and conditions
in the contract (the Order) specifying what happens if the commitments
are not met.  These terms and conditions could be embodied in the
collaboration model so as to determine the appropriate compensating
events.

Receiving discrepancies are another rich set of fulfillment problems,
which may call for other compensating events.

When all the commitments are fulfilled, the collaboration pattern
is ended.  (From a business perspective, that is the completion
of a *business* transaction.)

Harking back to the stories of document use and abuse,  the
collaboration model must define which business documents
and commercial transactions signify economic events, and which
are auxiliary information distributions. In other words, the mapping
from business document to economic event is not a given, it is
a matter of agreement among the trading partners.

* Contract Negotiation

In contract negotiations, the negotiating parties are attempting to agree
on economic commitments.  Economic commitments need to be
mutual (both parties must agree) and reciprocal (there must be a
consideration or something in return for something promised).

Negotiation implies that the process of agreeing to mutual and
reciprocal commitments may take several steps or back-and-forth
commercial transactions.  During the process of negotiation, the
commitments are not yet "committed" - they are in some other
state.  Negotiation is usually modeled as a state model, where
the states are those of the commitments, e.g. Offered, Countered,
Rejected, Accepted, etc.

I do not think it is up to ebXML to specify a state model for
negotiation.  Several other groups, including OMG and FIPA,
are already doing this.

http://www.osm.net/ecdtf.html
http://www.osm.net/upload/99-03-01.pdf
"Negotiation Facility Final Revised Submission"
"This specification provides a framework for collaboration on which
negotiation leading to
agreement and subsequent engagement can be established as contractually
binding
commitments."
http://www.fipa.org/repository/ips.html
(Need to be a member to look at these, unfortunately,
but the state charts are similar.)

Software to manage negotiation processes must be able
to keep track of and manage the states of the commitments
and the contract as a whole.

Such state management is almost certainly not handled by
existing internal business applications.  Until the commitments
are accepted, the contract is not really ready for most internal business
applications, which assume accepted orders. Moreover,  the states
are not really internal, but part of the public semantics of the business
collaboration. And the states of the commitments determine what
commercial transactions could happen next.

The Economic Contract and Economic Commitment classes
and their relationships as shown in Figure 7 of the ebXML
metamodel are a starting point for software to manage
negotiation states.  There is a little more work to do, which
will happen after Tokyo, but a negotiation process could be
modeled for Vancouver.


Hope this all communicated clearly.  Feedback welcome.
Assuming I get some encouragement, I'll keep going.

Respectfully,
Bob Haugen