DEMO (Design Engineering Methodology for Organization) has its foundation in DEMO Enterprise Ontology (DEO) and provides a strong theoretical foundation for business process modeling with truthful state machine with well-defined states and state transitions. The DEMO co-creation and co-production model, which is in some way an extension of the DEMO generic pattern, enables to capture not only production facts but also semantically related coordination facts. This ability empowers this model to express complex entities such as a contract not only in a descriptive way but in a prescriptive way with precisely defined states and state transitions. The paper deals with possibilities of the DEMO co-creation co-production model to capture contract and its truthful states.
common features of these phases will be discussed in the contract modeling section. The REA exchange process including a contract entity is illustrated in Fig. 1. The REA model is composed of two different kinds of transactions (decrement/ increment) in which one kind of transactions is in consideration of the other kind of transactions. The contract itself is related to these different kinds of transactions through the clause and party relationships.
«party»
Contract «clause» «clause» «inflow reservation»
Increment
Commitment «committed value receive»
1..* «fulfilment» 1..* 1..* «exchange 1..*
reciprocity» «committed provide»
Decrement
Commitment value 1..* 1..* «party» «committed receive» «receive» «outflow reservation» Economic Agent «receive» «provide»
1..* Increment Event value «inflow»
1..* Economic resource «committed provide» «fulfilment»
Economic Agent 1..*
1..* «exchange duality» 1 Claim
1 value to decrement 1 value to decrement 1 value to increment value to increment
1..* Decrement Event value 1..* «outflow» «provide» Economic Resource
The different kinds of transactions are related to each other by the duality and the reciprocity relationships. The claim entity is a temporary entity that helps to balance time discrepancies between different kinds of transactions. Transactions may not be performed at the same time which calls for this temporary entity.
The whole REA model provides descriptive knowledge about the enterprise with the focus on production actions (production facts) brought about by economic events.
DEMO is an engineering methodology to derive conceptual models of enterprises,
based on an ontological theory, DEMO enterprise ontology (DEO) [
A fact is a proposition that can be either false or true, to be validated by empirical observation. A fact may encompass a single object, or may encompass more objects. Depending on the number of objects that are involved in a fact, we speak of unary, binary, ternary, etc., facts. An example of unary fact is that Vendor is a Person. Another example of binary fact is that a Customer receives a Pizza.
In DEMO modeling enterprises are represented by discrete deterministic systems that may exist in a set of precisely defined allowed states. For each state there is a set of allowed transitions to another state, the so-called state transition space. All other state transitions are forbidden and cannot occur. In general, a state is determined by the set of facts that exist at that moment. A state change or state transition consists of one or more facts starting or ending to exist. The occurrence of a transition at some moment is called an event.
Events are widely defined as "things that happen in the real world", and that cause some effects. In DEMO there exist only i) communication facts, that are brought about by actor’s communication, following the transaction pattern; ii) production facts that describe the production of a specific actor; and iii) facts, that are caused by acts in the real world that may become true or false. Example i): the pizza has been requested by the customer and promised by the pizza baker, a contract has come into existence. Example ii): the production fact of the pizza baker is a pizza margarita. Example iii): the exchange rate between the US dollar and the EURO is 1.234. By empirical observation of the real world this fact is either true or false.
In order to truly capture the relation between two different kinds of transactions
(the case of the REA model) the DEO was extended by the FAR (Fact, Agenda, Rule)
ontology. In the FAR ontology [
DEMO modeling has a good body of empirical appropriateness for many different
areas of enterprise modeling in the professional world [
Many highly specialized enterprises do not have a well-defined portfolio of products with fixed prices but offer their capabilities to meet the specific requirements of their Principals. We define as follows here: co-creation captures the principal and the contractor(s) working together on the engineering of an acceptable artifact; coproduction captures the shared production of the engineering artifact by both principal and contractor(s), including matching financial transactions.
The proposed CC-CP Construction Model is shown in Fig. 3, with two compound
actors, Principal and Contractor [
Transaction T-1 represents a production fact the definition of what the production to be delivered by the Contractor must be. Typically production specifications with quality criteria, materials used, testing procedures to be followed. Usually this transaction can capsulate other transactions for engineering, product development etc. If T-1 is Stated and Accepted then there is a shared agreement, without any ambiguity, between Principal and Contractor about what the co-production must be.
Transaction T-2 represents as production fact the definition of the price, including specific payment terms and conditions, etc. precisely applied to the production defined by the transaction result of T-1. T-2.Accepted means that the two actors agree that there is a well-defined price for the production. However, price negotiations may occur here; a T-2.Stated is a quotation that can be accepted or rejected. One option is that there is no agreement, for example the production in this way is too expensive. This is a common situation, leading to the possibility to revoke T-1.Accepted and T-1.Stated and redesign the production in T-1 via a renewed T1.Request and T-1.Promise.
This phase represents the situation that there is a well-defined but yet unsigned contract on the table. It is important to realize that a contract is not the delivery of goods/services itself, a contract is a binding commitment to deliver goods/services/payments in both directions, depending on certain defined conditions. The two signatures on the contract are represented by T-3.Promised and T4.Promised. The act “Promise”, done after a “Request”, is the act of signing a contract. The resulting fact “Promised” is the factual existence of that signature, resulting in contract commitments and obligations. There are two parties involved in signing a contract, so both must perform the act “Promise” for their part of the contract. Transaction T-3 represents the commitment, an obligation that the production has to be delivered by the Contractor, executor, to the Principal, initiator. This obligation is not identical to the actual delivery of productions.
At some moment one of the actors – contract parties – may claim that his/her part of the contract obligations has been fulfilled, and communicates the communication act “State”. The other party may communicate the communication act “Accept”, which represents a shared agreement that the contract obligations have been fulfilled. The alternative is a communication act “Reject”, which represents a dispute, the contract has not (yet) been fulfilled.
Similarly, transaction T-4 represents the obligation to pay the price to be paid by the Principal, executor, to the Contractor, initiator. Contract disputes are very common and may involve either the payment, or the production or both. Parties may reach agreement that the contract has been fulfilled partially, only correct payment of the price (T4.Accepted) or correct delivery of the production (T-3.Accepted).
The actual co-production is captured by one or more instances of T-5 and T-6 transactions, representing one or more delivered productions and payments. Since the Contractor signed the contract, he has the obligation to issue T-5.Promise for multiple deliveries of productions, as long as the T-5.Request fits within the contract. The coproduction phase encompasses also multiple payments, instances of T-6. Often an instance of T-6 is directly related to an instance of T5, as stipulated in the contract. The co-production phase ends when the Principal and the Contractor have fulfilled their obligations defined in T-3 and T-4. The fulfilment of the obligation of ProductionAgreement by instances of T-5 will result in T-3 being Stated and Accepted. Similarly, the fulfilment of the obligation of PriceAgreement delivered by instances of T-6 will result in T-4 being Stated and Accepted. The contract has been fulfilled by both parties.
The DEMO CC-CP model enables to explicit distinguish between different kinds of contract’s phases. The most important is the distinction between a contract in which production and price were defined but not yet signed (co-creation phase) and signed contract (contract phase). From the REA point of view, this distinction enables to distinguish between a resource entity (represented by an unsigned contract) and an information entity (represented by a binding contract). A contract, which is prepared to be signed (the result of co-creation phase) in a REA terminology represents a resource entity with all its attributes. The contract, which was signed becomes an information entity which ‘controls’ others subordinated entities such as commitments.
The whole model is expressed in six principal DEMO transactions. Coordination facts, production facts, and aggregated facts enable to precisely describe all contract states. T-3 and T-4 DEMO transactions play a crucial role in this model because they capture the states of the contract. The aggregated coordination fact T-3.Promise and T-4.Promise represent the two events in which the contract is signed and becomes mutually binding. Finally, the aggregated coordination facts T-3.Accept and T4.Accept stand for the fulfilment of the contract.
The co-production phase represents a phase in which all details about ProductionAgreement and PriceAgreement are carried out in the forms of ProductionDeliveries (instances of T-5) and Payments (instances of T-6). The asynchronous execution of DEMO transactions eliminates any need for temporary claim entities.
In addition, the DEMO CC-CP Action Model enables to define rules that define the sequence of transaction execution – business rules. For example, a common situation such as: “pay first, then receive the goods” can be modeled and executed in production. It is in production impossible to receive goods before payments have been made. Much more detailed rules can be devised to capture any imaginable business model and matching contract.
The DEMO CC-CP model, as described earlier, distinguishes three phases for contract modeling whereas the ISO Open-edi Phases of a Business Process standard, utilized in REA business process modeling, defines five phases. This standard distinguishes between the following phases: Planning, Identification, Negotiation, Actualization and Post-Actualization. When semantic comparison between the ISO standard and the DEMO CC-CP model is performed the following results are received. The co-creation phase of the DEMO CC-CP model is an equivalent to the Planning phase, Identification phase and the Negotiation phase of the ISO standard. The contract phase and the co-creation phase of the DEMO CC-CP model can be compared to the Actualization phase of the ISO standard. The DEMO CC-CP model currently does not deal with the Post-Actualization phase of the OSI standard. Involving the Post-Actualization phase of the OSI standard into the DEMO CC-CP model would necessitate precise formal description of this phase and this will be one of the aims of the future research.
The paper describes and explains the principal characteristic and capabilities of the DEMO CC-CP model. The significant feature of the model is that it not only provides prescriptive control of the process execution but it also delivers descriptive knowledge (facts) about the modeling domain. In addition, all these facts (production, coordination) capture the modeling reality with good empirical evidence. These capabilities can be further utilized in construction of the REA model on the basis of the DEMO CC-CP model delivered facts. In this way, the REA model could obtain precise and complete data representation including information and business events. Delivered facts (factual knowledge) cover events such as: an invoice payment was requested; an invoice payment was declined (due to some discrepancies); an invoice payment was accepted. These facts represent coordination facts that constitute the DEMO complete transaction pattern and the facts declared in the FAR ontology. This approach would increase considerably REA modeling capabilities because it could utilize precise, consistent and coherent DEMO ‘infrastructure’. However, complete validation has to be done.
In terms of the contract entity itself, the DEMO CC-CP model provides clear and explicit distinction between contract’s phases in the form of states ad state transitions which are in compliance with modeling reality.
When comparing the contract phases of the DEMO CC-CP model with the phases of the OSI standard it can be concluded that there is mutual compatibility apart from the Post-Actualization phase which has not been yet included into the DEMO CC-CP model. This is the task for the future research.
The DEMO CC-CP model is suitable for execution by a software state machine for production and has been subjected to early software validation.