Flexibility of business processes requires a modeling language that can distinguish between the stable and flexible parts of a business process. Starting from a general model of business interaction, we develop the model of the stable part in the form of an Collaboration Model. We assume that changes of this model are rare and carefully planned. The flexible part is stored in socalled business rules that can be changed on an ad-hoc basis.
Flexibility of business processes requires a modeling language that can distinguish between the stable and flexible parts of a business process. Before this separation can be done we have to perform a thorough analysis of the business interactions within the organization and between organizations. To do so we make use of a particular modeling language called DEMO (Dynamic Essential Modeling of Organization). The result of the business process analysis is a particular DEMO model, the Interaction Model, that is subsequently refined into a set of Transaction Models.
The latter are then used as a basis for separating the overall behavior into stable and flexible parts. Behavior that is considered to be relatively stable over time is encoded in a specific diagram that represents the stable part. Formally this diagram is a Collaboration Diagram as specified by UML (Unified Modeling Language). Such a diagram has to be designed carefully so that changes in this model tend to require some time and effort. Hence its flexibility is low. Behavior that has to be adapted frequently is therefore represented in the form of business rules. These rules can be specified and changed in an ad-hoc fashion so that they provide high flexibility. The overall process is depicted in fig. 1. The remaining sections of the paper are structured as follows. First we give an overview of the Business-Action Perspective on Organizations which includes the Interaction Model and the Transaction Models. Based on the latter we introduce a procedure to split the behavior into a stable and a flexible part called Collaboration Model and Business Rules, respectively, and show how they can be derived from the detailed description of the business interaction that is contained in the Transaction Models. All examples and figures used in this paper are excerpts from the real models we designed in the course of a consulting project where we tested the feasibility of our approach. Last but not least we conclude this paper by summarizing the main arguments. 2
At the core of the Business-Action Perspective is the Speech-Act Theory by Austin
and Searle [
The Business-Action Perspective offers many approaches some of which we have already mentioned. We have chosen DEMO because it offers transactional patterns not only in the meta-language but also as concepts in the modeling language itself. This allows us to distinguish between transactions (as complex business actions) and business acts (as elementary actions) which is essential for our approach (see section “Transaction Models”).
In DEMO, all acts that serve the same purpose are collected in a transaction in
which two roles are engaged: the initiator and the executor. A transaction is assumed
to follow a certain pattern which is divided into 3 sequential phases: order (O),
execute (E) and result (R). In the order phase the contract is negotiated. This involves
typically a request being made by the initiator and a promise by the executor to carry
out the request. In the next phase the contract is executed which involves factual
changes in the object world (as opposed to the inter-subject world of communication).
Finally, in the result phase the executor states that the agreed result has been achieved
and the initiator accepts this fact. If anything goes wrong on the success layer, the
participants can decide to move to the discussion or discourse layer. For details on the
layers see [
The Interaction Model shows actors and transactions. The actors are roles that are enacted by a person, an organizational unit or a whole organization. Fig. 2 shows the Interaction Model of our case. The main actors are the Logistics Provider, the Headquarters of the retailer and the Shop. The latter two maintain a very close, franchise-like relationship. Fig. 2 describes the process of capacity reservation and order handling among these organizations. It starts when Headquarters reserve capacity for handling a certain amount of ordered items in advance of the actual order (T4). The Logistics Provider (LogPro) allocates staff and space so that the reserved capacity can be provided at the time the respective order arrives. Orders for products can be initiated either by Headquarters or by the Shop. The former happens when the Shop is running low on certain products. Headquarters will in such a case suggest to the Shop to place a refill order (T2). If customers ask for specific products, the Shop can also place a so-called customer order (T1). Headquarters will forward both types of orders to LogPro (T5). The delivery to the Shop will then be performed by LogPro and the Shop receives the delivery (T3). Periodically Headquarters will also ask for an update of the stock (T6). 2.2
Much of the detailed behavior that constitutes a business process is hidden inside each transaction. For the specification of the stable and flexible process parts this has to be brought to light. A transaction in DEMO is made up of a number of business acts and the contracted action. The actagenic conversation (O phase) has at least two elements: a request and a promise (see fig. 3). If an agreement was reached in the order phase, the contracted action (E phase) is executed and the factagenic conversation (R phase) is entered. As a minimum this can consist of the business acts state and accept. Fig. 3 summarizes these steps which are performed in the order that is indicated by the leading numbers. A model that contains only actors, business acts and contracted actions is called a Business-Act Model. A Business-Act Model that contains only actions and actors belonging to one transaction is called a Transaction Model. 3
When developing the Collaboration Model and Business Rules we look at each transaction in turn. We first create a Business-Act Model of the respective transaction. The result is a very detailed model with all the steps that have to be performed in the course of the transaction. Fig. 4 shows as an example the Business-Act Model that corresponds to transaction T5. The aim of that transaction is to fill the order, i.e. to deliver the items contained in the order. It starts when Headquarters send a so-called pick list to LogPro. This list names the products to be picked (and delivered) and their quantities. The associated activity is a stable activity and the information is important for controlling the process of filling the order. It will therefore be entered into the Collaboration Model (see fig. 5). The information systems of Headquarters and LogPro are integrated in such a way that the list is sent electronically as a “pick file”. The next step in transaction T5 is that LogPro confirms the receipt of the pick list. As the warehouse management system of Headquarters mirrors that of LogPro an out-ofstock situation occurs rarely. LogPro only has to confirm that enough resources are available (staff, shelf space) to handle the order. As the reserved capacity (T4) is usually sufficient an explicit confirmation is not required but is per default assumed. The respective business act does not appear in the Collaboration Model. Instead we create a Business Rule for the exception, i.e. if the required capacity does exceed the reserved one by more than the allowed margin (see table 1, T5, promise). This implies that we can change this behavior more easily than that in the Collaboration Model. For example, if the allowed margin changes we only have to adapt the condition clause of the rule. The Collaboration Model would not have to be redesigned in such a case. This increases the flexibility of handling situations that might require changes.
If ‘confirm receipt’ was O.K. no further message is sent.
Otherwise the claim is processed (return/resend).
A request for a capacity (forecast of required capacity) is always accepted and hence not confirmed.
The provision of the requested capacity is guaranteed.
Hence no confirmation is required. promise The pick list is accepted per default, no confirmation is sent.
If the amount of items to be picked exceeds the limit specified in the general terms and conditions of this agreement (in relation to the reserved capacity), a special arrangement is made (rescheduling of warehouse staff / T6 accept request, promise higher unit price).
This is implied by the receipt of the delivery. If items are missing or wrong ones have been sent a respective complaint is sent to LogPro and wrong items are returned to LogPro.
The updating of the retailer’s warehouse system is done via an automatic, daily file transmission containing a stock report. Request and promise are therefore obsolete.
The receipt of the stock report is assumed. If transmission fails, manual troubleshooting will be invoked.
The next step in transaction T5 is that LogPro reports the delivery. This is a stable activity and Headquarters needs this information for billing purposes. It is therefore a part of the Collaboration Model. The final step, confirm delivery, is implied by the receipt of the delivery (T3). The exceptional case of a wrong delivery is handled in a flexible manner by Business Rule T5, accept (see table1).
The same is done for the remaining transactions T1 – T4 and T6. This ultimately leads to the complete Collaboration Model in fig. 5 and the complete list of Business Rules in table 1. 4
A model of the business interactions in organizations can contribute towards the separation of stable and flexible behavior. In particular, DEMO’s Interaction Model allows us to develop first the Transaction Models and ultimately the stable and flexible parts of the business process: Collaboration Model and Business Rules. The former represents stable behavior that is carefully planned and designed and therefore provides little flexibility. It is formally a reduced version of the complete BusinessAct Model that provides the same level of precision. Changes in this model can be effected, though, but they take some time and effort. The latter part, Business Rules, on the other hand offers much more flexibility because changes in behavior are often locally restricted and can be handled by adapting a particular rule. This requires typically only to change the condition of the rule or the triggered activity. On the whole this approach allows us to manage the flexibility and adaptability of business processes in a structured way by identifying the flexible part of the overall behaviour and treating it in a way that facilitates change.