[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC