Modeling Business Processes:

Transcription

1 Int'l Conf. Modeling, Sim. and Vis. Methods MSV'17 61 Modeling Business es: Events and Compliance Rules Sabah Al-Fedaghi Computer Engineering Department Kuwait University Kuwait Abstract Business process modeling has become a main tool for capturing, analyzing, and developing business activities. Each business process model acts as a blueprint for instances. The ordering of activities can be controlled through process orchestration that includes a choreography representing the start and end events of the interacting processes. Events play a crucial role in expressing interrelationships between business processes. This paper re-explores the notion of events in business processes through proposing that an event is a thing that can be created, processed, released, transferred, and received. This idea is developed such that events are recognized from the description of the processes involved. Accordingly, the choreography of the execution of processes can emerge from the specification of events. The same idea can be applied in the area of ensuring compliance with imposed rules, where the problem is how to specify the constraints and rules in preparation for applying them. The system description (schemata) can be constructed from the compliance rules. Keywords business process compliance; process modeling; diagrammatic language; conceptual model I. INTRODUCTION Business processes refers to those activities that take inputs and create an output that is of value to the customer [1]. A process itself is described in an abstract description of a collection of activities []. One example is an ordering procedure, where an order is received and processed, an invoice is sent, payment is made, and the products are shipped. Business processes are considered the key instrument to organizing business activities and to improving the understanding of their interrelationships. Information systems play an important role in supporting such processes []. In many companies there is a gap between organizational business aspects and the information technology that is in place. Narrowing this gap between organization and technology is important, because in today s dynamic markets, companies are constantly forced to provide better and more specific products to their customers. [] Business process modeling has become a main tool for capturing, analyzing, and developing business activities. Summarizing from Weske [], a model consists of activity models and execution constraints. An instance represents a concrete case in the operational business of a company. Each business process model acts as a blueprint for instances. The ordering of activities can be controlled though process orchestrations in a similar manner to a conductor who centrally controls the musicians in an orchestra. The process choreography represents start events and end events of the interacting business processes. modeling techniques include event-driven process chains. Events play a crucial role in expressing interrelationships between business processes. Events are happenings in time and space. In business process modeling, an event represents a state transition [emphasis added] of an activity instance []. This paper reexplores the notion of events in business processes. According to Penicina and Kirikova [], there is a gap between business process models and lawful states of business objects. This gap hinders compliance of business process models with internally and externally imposed regulations. Existing modeling methods such as BPMN and ArchiMate lack an explicitly declarative approach for capturing flow of business objects, their states and laws of state transitions [emphasis added]. Such deficiency can cost organization potential legal problems, make the ability of BPMN and ArchiMate to capture real-world phenomena questionable and drive modelers to employ additional standards. This paper contributes to the area by introducing an alternative approach to conceptualizing events where an event is a thing (to be defined later) that can be created, processed, released, transferred, and received. This idea is developed such that events are recognized from the description of the processes. Accordingly, the choreography of the execution of processes can emerge from the specification of events. The same idea can be applied in the area of ensuring compliance of business processes with imposed regulations stemming from various sources, such as security constraints, domain-specific guidelines, corporate standards, and legal regulations [4]. The system description (schemata) can be constructed from the compliance rules. The next section will review the diagrammatical modeling tool that will be used in process specification. This tool will be used in section to illustrate the modeling techniques and, simultaneously, to develop the notion of events. II. DIAGRAMMATIC LANGUAGE:REVIEW This section summarizes the Flowthing Machine (FM) model [5, 6], which provides a diagrammatic language

2 6 Int'l Conf. Modeling, Sim. and Vis. Methods MSV'17 proposed as a high-level description suitable for event-like notions. FM is a generalization of the well-known input process output model, utilized in many scientific fields. It involves handling of flow things: things that can be created, processed, released, and transferred, arrive, and be accepted as shown in the flow system depicted in Fig. 1. If all things that arrive are accepted, the Arrive and Accept stages can be combined into a single stage. Hereafter, a flow thing will be referred to merely as a thing. The arrows in the figure represent flows of things. Fig. 1 can be considered as a type of abstract machine. Accept Fig. 1. Flow system. (in/output) Arrive The environment of flow is called its sphere (e.g., data flow within the sphere of a company). Note that a flow system itself is a special type of sphere. The stages of a flow system are mutually exclusive; that is, a thing always exists in one and only one of these states or stages at any moment. Assuming the thing is a datum, in this model is any operation on the datum that does not produce a new piece of data. Creation denotes the appearance of a new datum in the flow system. There are many types of things, including data, information, money, food, fuel, electrical current, and so forth. The life cycle of a thing is a sequence of stages through which it passes in a stream of flow. Other states of things, for example, stored, are secondary states; thus, we can have a stored created thing, a stored processed thing, and so forth. In addition to flows denoted as arrows, FM includes triggering mechanisms represented by dashed arrows. Triggering denotes activation, such as starting a new flow. III. MODELING AND EVENTS Weske [] gives an example of an ordering process of a reseller company that is shown as a set of activities performed in a coordinated manner. The coordination between the activities is achieved by an explicit process representation using execution constraints [emphasis added]. The process starts with the company receiving and checking an order, followed by activities in concurrent branches [emphasis added]. In one branch, the invoice is sent and the payment is received; in the other branch, the products are shipped. When both branches complete their activities, the order is archived, and the business process terminates. Concurrent activities can be executed [emphasis added] in any order, and any overlap in the execution time of concurrent activities is allowed.... The ordering process can be used as a blueprint [emphasis added] that allows the reseller company to organize its work.... Each order that is processed according to this model is a business process instance. Therefore, there is a one-to-many relationship between business process models and business process instances. [] Figure shows the corresponding FM representation. Because of the simplicity of the example, different flows are not included in boxes. In the figure, the order is received and processed (circle 1) to trigger the creation of an invoice (). The invoice flows to the customer who sends the payment () and this triggers processing (e.g., packaging) and sending the shipment (4). 1 Invoice Payment 4 Shipmen t Fig.. FM representation of the example Note that the FM representation has no start or end. These are dynamic features that appear at the execution level through what we call events. Events are also flow things that can be created, processed, and so on. Usually, the concern in business modeling is with meaningful events. From the description of the problem in the example above, it seems that the interest is in the following events. Receiving an order (V 1 ) ing an order (V ) Creating and sending an invoice (V ) Receiving payment (V 4 ), and Shipping the product (V 5 ). Figure shows these events in the example of the reseller company. V 1 V V Invoice The Business Model and Notation, BPMN [7] is used to model this process of a reseller company. In BPMN, activities are represented by rectangles with the name of the activity. Events are circles with icons (e.g., envelope, indicating the type) that mark the start and end of the process. V 4 V 5 Fig.. Events Payment Shipmen t

3 Int'l Conf. Modeling, Sim. and Vis. Methods MSV'17 6 These events can be ordered according to desired implementation. V 1,V,V,V 4, V 5 V 1,V,{V,V 4 }, V 5 ; where the curly brackets indicate parallelism. It is also possible to split V 5 in Fig. into two events, retrieving and processing (e.g., packaging) the product, V 5 in Fig. 4, and transferring the product to the customer, V 6 in Fig. 4. In this case we can order the events as V 1,V,{V,V 4, V 5}, V 6. V 6 Fig. 4. Dividing V 5 of Fig. into two events Shipmen t V 5 Accordingly, modeling the dynamic behavior in FM is a phase separate from the task of describing static actions (Fig. ). The start and end in the BPMN diagram of the reseller company (see Weske []) belongs to a different ontological level than action descriptions such as receiving an order, issuing an invoice, and so on. The static description (Fig. ) is the abstract definition while the dynamic behavior is its realization in time. For example, the definition of rain is moisture condensed from the atmosphere that falls visibly in separate drops (can be modelled in FM). It has no start or end. But, the event of rain can be objectified as the rain in New York at 7:15 that lasted until 8:10 on a certain date as modelled in Fig. 5. For simplicity s sake, the time flow was not shown in previous descriptions of events (Figs. and 4). The time specification of an event reflects the singularity of events (they can only occur once). The body of the event in the modeled context is what lives though the event (i.e., in Fig. 5: moisture, drops, flows). It is the things out of which the event is constructed in addition to time. Event: Raining in New York Moisture : condensed : takes its course Drops Ground Fig. 5. An event involves a sequence of actions at a specific time Time Figure 5 provides a clear illustration of the notion of the event raining in New York. Events can be interrelated (e.g., intersections, sub-events) and have properties (e.g., intensity or how swift is the performed operation is), and so on. In this conceptualization, events are not such BPMN events as start and end; rather they are what lives though the process (e.g., moisture, drops, and flows) in time (Fig. 5). In the field of process modeling, there are different ideas regarding the typical treatment of events. As stated in the introduction, for Weske [], a state transition of an activity instance is represented by an event. In another place, he says, Examples of events are the receipt of an order, the completion of processing an order, and the completion of shipping a product. In FM terminology, these are bodies of events or what live though them. This example shows a different approach to business process modeling by producing a flow-based schemata and then specifying events of interest as sub-diagrams of the representation of the system. According to defined requirements, we can select different types of execution of events for the reseller company as shown in Fig. 6. The FM representation embeds operational semantics (e.g., run-time execution) that simplify the simulation of the chronology of events. The resulting operational semantics are conceived along a causality model specification in which events are used to define fine-grained behaviors. V V 4 V 5 V 6 V 1 V V V 5 V 6 IV. APPLICATION: COMPLIANCE RULES This Lego-like technique that constructs a (big picture) schema from pieces can be applied in different design ventures. According to Knuplesch and Reichert [4], A fundamental challenge for enterprises is to ensure compliance of their business processes with imposed compliance rules stemming from various sources, e.g., corporate guidelines, best practices, standards, and laws.... Providing a visual language is advantageous in this context as it allows hiding formal details and offering an intuitive way of modeling the compliance rules. However, existing visual languages for compliance rule modeling have focused on the control flow perspective so far, but lack proper support for the other process perspectives. V 4 V V 4 V 5 V 6 Fig. 6. Possible sequences of events

4 64 Int'l Conf. Modeling, Sim. and Vis. Methods MSV'17 They introduce an extended Compliance Rule Graph language, which models compliance rules utilizing a healthcare scenario dealing with compliance rules and processes captured in the context of a large process engineering project in a university hospital. Diagrams significantly increase the comprehensibility of and foster communication among business analysts and subject matter experts on one hand and process engineers on the other. Notations for compliance rules include Compliance Rule (e.g., Graphs [8] and BPMN-Q [9]) and process modeling languages (e.g., YAWL [10], and BPMN [7]) combine an intuitive notation with the advantages of a formal language. [4] In the following subsection, some of Knuplesch and Reichert s [4] compliance rules are given and their FM representations are drawn. As we did with events, the compliance rules will be used to produce a flow-based schemata where rules become an integral part (sub-diagrams) in the composition of the total representation of the system..1 Compliance Rule 1 For an inpatient, an x-ray examination must be ordered by a ward physician. The same physician must fill in the respective order form. ([4] based on [11]) Figure 7 shows the FM representation of this rule. The patient flows to the physician (circle 1) to be processed (), accordingly, an x-ray order is created (). For simplicity s sake, the patient and x-ray things are not enclosed in a box. 1 Fig. 7. Rule 1 Figure 7 is a rule in the sense that it describes a specific situation where a patient is processed by a physician and, accordingly, an x-ray order is issued. This rule would melt in the system schema, thus, it is the only flow that generates an x- ray order. This realizes the MUST in the rule. It is analogous to specifying that electricity for an air-conditioning unit in a building must come directly from the main power supply. In this case, the schemata of any building includes a direct supply line from the main electricity supply to the unit. The schema expresses the constraint in a diagram instead of in English. As will be shown later, all constraints are merged to form the schemata of the healthcare scenario in the involved hospital. In Fig. 8, the patient (accompanied by his/her x-ray order) flows to the (1) to trigger the creation of informed (). This, in turn, triggers releasing the patient () to go to the radiologist (4) to produce the x-ray image (5). 1 Fig. 8. Rule The figure specifies Rule through modeling it as a flow system. The patient cannot flow to the without an x-ray order and as soon as he/she arrives, an informed is produced to permit him/her to go to the radiologist.. Compliance Rule Diagnoses shall be provided by physicians only after receiving all x-ray images from the radiology department; i.e., no x-ray image may be received afterward. [4] As shown in Fig. 9, x-rays are received and processed () to keep track of the arrival of all of them. The process stage may store the x-rays until all arrive, then trigger the diagnoses of the patient (). This is performed within the sphere of a physician of a patient. As will be discussed later, instances of such an process will be tracked by events. : Diagnoses : All? Fig. 9. Rule.4 Compliance Rule 4 Before requesting an informed, a physician must inform the patient about risks. [4] In Figure 10, the informed is created only as the result of receiving and processing risks flowing from the physician Compliance Rule An x-ray examination in the radiology department must be performed by a radiologist. Before the exam, the informed of the patient must be received and checked by a medical technical assistant () in the radiology department. [4] : Fig. 10. Rule 4 Risks

5 Int'l Conf. Modeling, Sim. and Vis. Methods MSV' Compliance Rule 5 At least one day before a surgery takes place, blood bags must be ordered. As shown in Figure 11, when the date of a surgery is decided (1), then the processing of this data includes watching the specified range (at least one day) to trigger () ordering blood bags that flow to, say, the blood bank, that process such an order () and release and transfer the ordered blood bags to the surgery. Note that a surgery, here, denotes a recognizable work unit..6 Compliance Rule 6 If an additional x-ray examination is ordered to prepare a scheduled surgery, the x-ray must be completed before the surgery. This rule is similar to rule, but, here, the ordered x-rays are triggered by the preparation for surgery (see Fig. 1)..7 Compliance Rule 7 A patient shall be formally admitted within one week after her referral to the hospital. As shown in Fig. 1, the referral and its date flow to the hospital (1) where the date is processed () such that within one week, it triggers () the creation of admission of the patient. V. A COMPLETE DESCRIPTION FROM THE RULES The given rules can be merged to form a complete conceptual description of the hospital as shown in Fig. 14. First, the referrals (1) of the patient () flow to the hospital (). Within one week (4), he/she is admitted to be under the care of a physician (6). In this situation the patient is sent to the radiology department (7) to: have x-rays taken (8) and have additional x-rays taken (9) in preparation for surgery. Referral Hospital 1 4 Fig. 1. Rule 7 : Admission : within one week Blood bags Surgery : At least one day 1 4 Fig. 11 Rule 5 Additional x-ray Preparation for surgery Fig. 1. Rule 6

6 66 Int'l Conf. Modeling, Sim. and Vis. Methods MSV'17 Diagnoses (10) are provided by physicians only after receiving all x-ray images (x-rays [11] and additional x-rays [1]) from the radiology department. For simplicity s sake, the familiar notion in computer science a thick horizontal line (1) is used to denote a synchronization of the conditions of receiving ordered x-rays and additional x-rays. Upon deciding the surgery date (14), blood bags (15) are ordered as explained previously in Rule 5. Additionally, the informed (16) is received after the physician explains the risks involved (17). The resultant big picture of the integration of rules embeds them all; hence, the rules are enforced by design. Additionally, the integration can expose the interrelations between rules, thereby optimizing their design. For example, it seems that Rules 1,, and 6 (see Fig. 15) that deal with x-ray orders and additional x-ray orders can be coordinated to produce a better designed diagram. 1 Referral Hospital 4 : within one week 6 : All? Preparation for surgery 7 Admission 5 Additional x-ray 1 : All? 1 : Diagnoses 10 : 16 Risks 17 : At least one day 14 Surgery 15 Blood bags Fig. 14 Integrated schemata of rules

7 Int'l Conf. Modeling, Sim. and Vis. Methods MSV' : All? 11 Rule 1 9 Preparation for surgery 8 Rule 6 7 Rule Additional x-ray 1 : All? 1 : Diagnoses 10 Fig. 15. Rules 1,, and 6 VI. CONCLUSION This paper has examined the notion of events in business processes by treating events as flow things. This idea is developed such that events are recognized from the description of the processes. Accordingly, the choreography of the execution of processes can emerge from the resultant specifications. This led to constructing the total diagrammatic description from the events diagrams which seems to avoid the complexity of building one schemata of the system. The same idea of developing a big picture specification from small diagrams has been applied to compliance rules imposed upon business processes with the goal of ensuring compliance with these rules. The rules have been specified and integrated to generate a system description (schemata). The proposed approach seems to be a viable alternative method for analyzing and designing business processes. Further research in developing FM modeling would enhance the understanding of basic notions such as events in the field of business processes. REFERENCES [1] M. Hammer and J. Champy, Reengineering the Corporation: A Manifesto for Business Revolution. Location: Harper Business, 199. [] M. Weske, Business Management. Berlin, Germany: Springer Berlin - Heidelberg, 01. [] L. Penicina and M. Kirikova, Towards compliance checking between business process models and lawful states of objects, nd International Workshop on Ontologies and Information Systems, 1th International Conference on Perspectives in Business Informatics Research Lund, Sweden, September 4, 014. [4] D. Knuplesch and M. Reichert, A visual language for modeling multiple perspectives of business process compliance rules, Software & Systems Modeling, 1 April 016. DOI: /s [5] S. Al-Fedaghi S. and H. AlMeshari, Social networks in which users are not small circles, Informing Science, Vol. 18, 05 4, 015. [6] S. Al-Fedaghi, Conceptualization of various and conflicting notions of information, Informing Science, Volume 17, pp , 014. [7] OMG: BPMN.0. Recommendation, OMG (011). /spec/bpmn/.0/ [8] L.T. Ly, S. Rinderle-Ma, and P. Dadam, Design and verification of instantiable compliance rule graphs in process-aware information systems, in CAiSE 10, LNCS, vol. 6051, Location: Springer, 010, pp. 9. [9] A. Awad, G. Decker, and M. Weske, Efficient compliance checking using BPMN-Q and temporal logic, in BPM 08, LNCS, vol. 540, Location: Springer, 008, pp [10] W.M.P. van der Aalst and A.H. ter Hofstede, YAWL: yet another workflow language, Information Systems, vol. 0, issue 4, pp , 005. [11] I. Konyen, B. Schulthei, and M. Reichert, Prozessentwurf f ur den Ablauf einer radiologischen Untersuchung, Tech. Rep. DBIS-15, University of Ulm, 1996.