RE: Economic relationships in business collaborations (long)

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Bob,

	I too loved your paper. I am not a "business" person but I 
think I understood it. And I would be very interested in the 
continuation !

Also, I think this mail clarifies to me many of the off-line 
questions we have been discussing togteher after the "BSI 
Proposal". As a first impression, I see a lot of potential of 
what you presented in the context of the BSI. It will be 
interesting to start working on the BSI by verifying its 
applicability to what you wrote as well as, perhaps, modelling 
the BSI to keep the notion of these patterns.

Please, continue your work on this ! 

Best regards

/Stefano

> 
> > -----Original Message-----
> > From: Bob Haugen [mailto:linkage@interaccess.com]
> > Sent: Thursday, November 02, 2000 12:07 AM
> > 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
> >