Process Management Whitepaper Dipl.-Ing. Walter Abel Managing Director Dipl.-Ing. Walter Abel Management Consulting Karl Czerny - Gasse 2/2/32 A - 1200 Vienna Phone: (+43 1) 92912 65 Fax.: (+43 1) 92912 66 office@walter-abel.at www.walter-abel.at www.itsmprocesses.com Dipl.-Ing. Walter Abel Management Consulting
Content Content... 2 1. Introduction... 3 2. Processes... 4 2.1 Basics of Process Architecture... 4 2.2 Basics of Process Modelling... 4 2.3 Process Components... 5 2.4 Modelling Guidelines... 7 2.5 Executable Processes... 9 2.6 Private Processes...10 2.7 Public Processes...10 2.8 Selection of Process Type...11 3. Collaborations...12 3.1 Black Box - Pools...13 4. Choreographies...15 4.1 Usage of Choreographies and Collaborations...16 5. Conversations...17 6. Summary...18 7. Sources...19 Dipl.-Ing. Walter Abel Management Consulting Page 2 of 19
1. Introduction Since the beginning of 2011 BPMN (Business Process Model and Notation) 2.0 is released by the Object Management Group (OGC). The most obvious novelty from the modeller s perspective is the enhanced set of possibilities to represent the interaction of different enterprises by comprehensive processes. Even the previous releases of BPMN differentiated from other process modelling notations by the possibility to model the information exchange between independent partners besides the description of the sequence flow. The constructs for modelling of comprehensive processes over the borders of the partner organizations have been remarkably enhanced within BPMN 2.0. Two new diagram types have been introduced: choreography and conversion. It is rather complex to get an overview of this variety of new ways to model comprehensive processes. In practice all these possibilities rarely will be used all together. To select the appropriate diagram types and modelling constructs a deeper understanding of their correlation is necessary. The specification of BPMN 2.0 contains besides others the following definitions: Process Orchestration Private Process Executable Process Public Process Collaboration Choreography Conversation Communication For the modelling of these concepts four diagram types are defined: 1. Process Diagram 2. Collaboration Diagram 3. Choreography Diagram 4. Conversation Diagram Dipl.-Ing. Walter Abel Management Consulting Page 3 of 19
2. Processes Within BPMN a process is defined as a sequence of activities (tasks) within an organization. In case processes are automated by the usage of web services the term orchestration is used. Orchestration describes the triggering sequence of these web services when a process is executed. The BPMN specification uses the terms process and orchestration more or less synonymously. BPMN 2.0 focuses on a detail level of process modelling that allows the direct execution of a process by a process engine of a workflow system or a business process management system. For the necessary tasks a lot of setailed constructs and attributes is available. Furthermore the exact meaning of modelable facts for execution was defined, the execution semantics. In case a process is modelled in a level of detail and attributes that allows automated execution by a workflow engine it is called an executable process. In case these details are missing the process is not executable. Exactly spoken the executability is not a feature of the process but of the process model. Within the specification we read simplifying about executable respective non executable processes. 2.1 Basics of Process Architecture For easy reading of company wide process models a hierarchical structure with constant level of detail per modelling level makes the utmost sense: 2.2 Basics of Process Modelling For the modelling of processes some basic rules are valid to ensure completeness and readability of the process pictures: Processes are modelled in chronological manner along the timeline. They always have a defined trigger and they always produce a defined business relevant output. All activities within a process have roles responsible for them located within the organizational structure and can be mapped with real persons. Dipl.-Ing. Walter Abel Management Consulting Page 4 of 19
A completely modelled process describes the way information is accompanying the flow of tasks. Variants of the process flow are described by branching of the process via gateways with defined criteria for the separate branches. 2.3 Process Components Common understandable process modelling requires standardization of used building blocks and terms of modelling. The main process components are: Process Task Process Owner Role Participant Gateway Event Connector Process A process is a recurring flow of activities (tasks - see there) with defined trigger and defined output. Each process has a person in charge of it (process owner - see there) and defined targets. Task A task is completed accomplishment within a process, which is not more detailed in the process level where it is performed. Process Owner The process owner is responsible for the correct operation of a defined process. He/she may, but not in every case, perform tasks within the process. Main issues are that: he/she is responsible for the outputs of the process from business perspective he/she has the organizational authority to gear into the process in a corrective or constitutive manner in case the process output does not meet the given targets Role A role carries a defined responsibility within the process organization. It has a specified assignment within the process: process owner responsible for defined tasks additional participant (see there) Roles can be mapped with the organizational structure and be there either unique (role sales manager ) or may exist multiple (role machine operator ). Dipl.-Ing. Walter Abel Management Consulting Page 5 of 19
They are held by physical persons. Physical persons may carry one or more roles. Within a correct organizational documentation the mapping of roles and physical persons are described within the job descriptions: jobs contain at least one role (link to the process organization) jobs are located within the hierarchy of the enterprise organization (link to the organizational structure) jobs are taken by physical persons Thus the connection between organizational structure and process organization is documented precisely. Participant A (additional) participant is normally connected to separate tasks. Possible duties are: processing a task (contribution to) approval of the result of a task information provision (the participant is consulted during execution of the task) information receiving (the participant is informed about the execution of the task respective the result of the task) Gateway A gateway serves for branching a process into either separate (alternative) flows or parallel (simultaneous) flows according to defined criteria and rules. Important is the precise definition of the branching criteria. Event An event (occurrence of a defined state) may: trigger a process (starting event) mark the result of a process (end event) interrupt a process (catching intermediate event) mark a defined state of the process (throwing intermediate event) Connector A connector describes the logic of the process flow. The main connectors are: sequence flow (describes the sequential arrangement of the tasks) information flow (describes the transport of information between activities, events and organizational units or roles) control flow (describes the controlling logic of the process, hence it is important for the execution by workflow engines) Dipl.-Ing. Walter Abel Management Consulting Page 6 of 19
2.4 Modelling Guidelines Each notation contains a huge amount of symbols to define the elements and the logic of a process. The same is with BPMN. A company specific standardization is mission critical and the wise restriction within the great variety of descriptional possibilities for process models as well. Important Symbole der BPMN 2.0 in Prozessmodellen Symbol Process Element Function Start Event Start Message Event Start Timer Event Start Conditional Event Start Signal Event Catching Intermediate Message Event Catching Intermediate Timer Event Catching Intermediate Conditional Event Throwing Intermediate Message Event Throwing Intermediate Signal Event End Event End Message Event End Signal Event End Terminate Event Data Based Exclusive Gateway Parallel Gateway Trigger for a process Message as trigger for a process Point in time as trigger for a process Changed conditions as trigger for a process Signal over process borders as trigger for a process Process waits for a message Process waits for a defined time to continue Process waits for changed conditions to continue Process sends a message and continues afterwards Process places a signal and continues afterwards End of the process Process ends with a message Process ends with a signal Process stops all open (partial) activities at branching the process follows a defined condition at junction each branch triggers the continuation of the process at branching all partial flows of the process are triggered at junction the process waits for all incoming partial flows Dipl.-Ing. Walter Abel Management Consulting Page 7 of 19
Inclusive Gateway Complex Gateway Task at branching one or more brancjhing flows are triggered according to defined conditions at junction the process waits for all incoming partial flows One or more branching flows are triggered based on a verbal description (only to be used when branching with high complexity if not to be described by using other gateway types) Activity based upon an organizational responsibility Parallel Multiple Task Sequential Multiple Task Subprocess Organizational Unit, Main Role (Pool) Role (Lane) Additional Participant Sequence Flow Message Flow Activity is performed more than once in parallel Activity is performed more than once one instance after the other Embedded independent and solitary flow of taks External and internal organizational units respective the main role of a partial process (if no lanes are defined) Leading role of the partial process within an organizational unit Additional role with defined operation and duty within the process Concatenation of tasks according to the flow logic of the process Concatenation of tasks by information transport Dipl.-Ing. Walter Abel Management Consulting Page 8 of 19
2.5 Executable Processes An example of a simple executable process in a process diagram is shown in Picture 1. This picture correlates with the BPMN versions, 1.2 and 2.0 as well.the basic objects for the modelling of a process have not changed with the new version, but some new ones have been added (but they are not used in this example). Picture 1: Process for creation of a centralized buying - shown is the executable process which is the view onto the workflow of the centralized buying process Trigger of the process is a demand documented by the provision of a purchase requisition. This is handed over to the business manager for approval via email (End Message Event). After approval, triggered by the incoming purchase requisition (Start Message Event), a transmission to the purchasing agent is performed (End Message Event). With the storage of the purchase requisitions, triggered by the incoming purchase requisition (Start Message Event) the process finishes in a defined status (End Event approved purchase requisition stored ). With the first working day of the month (Start Time Event) now the purchase requisitions are bundled and the check of delivery capability with the possible suppliers is performed. This is a multi instance activity performed for each item of a list (depicted by three parallel lines in the task symbol). In our case the enterprise works with a lot of suppliers. Each of them now is asked for delivery capability. Hence the activity is performed as often as suppliers are available. The inquiries are processed in parallel. As soon as all suppliers are asked the selected supplier is given from the incoming answers. Thus in our example there is no separation between a parallel activity for inquiry and a second activity for final selection. The further flow follows the above picture. Dipl.-Ing. Walter Abel Management Consulting Page 9 of 19
2.6 Private Processes This reduced view to the processes often is the basis for a process documentation following a process analysis. The graph only shows the internal logic of the task flow and the triggering, continuative and ending events. Picture 2: Process for the creation of a centralized buying - shown is the private process, which means the internal view of the enterprise to the centralized buying Trigger of the process is a demand documented by the creation of a purchase requisition. This is handed over for approval by email (Catching Intermediate Message Event, which means that the following steps are triggered immediately by the incoming purchase requisition). After der approval a second hand over for storing of the purchase requisitions is performed (again a Catching Intermediate Message Event as after intake of the purchase requisition immediately the storing is done). At the first working day (Start Timer Event) the bundling and the check for delivery capability with the possible suppliers is performed. This is again a multi instance activity performed for each item of a list (depicted by three parallel lines in the task symbol). In our case the enterprise works with a lot of suppliers. Each of them now is asked for delivery capability. Hence the activity is performed as often as suppliers are available. The inquiries are processed in parallel. As soon as all suppliers are asked the selected supplier is given from the incoming answers. Thus in our example there is no separation between a parallel activity for inquiry and a second activity for final selection. The process in Picture 2 shows the internal view of the enterprise at its own process. In BPMN such a representation of a process with all the internals is called a private process. In contrast to this the public process shows only the activities and events needed for the message exchange with partners. Parts of the process not relevant for the partners are skipped in that case. 2.7 Public Processes The public process shows the simplified external view to the process. Thus it needs to contain only the events and activities relevant for the information flow between the partners. Activities without information flow are skipped. In this example of a public process the purely internal activities like Create Purchase Requisition, Approve Purchase Requisition and Forward approved Purchase Requisition can be skipped. By that the gateway of approval decision is no more needed. With events it is to decide whether the partner needs them for understanding of the process respective the control of interaction. Dipl.-Ing. Walter Abel Management Consulting Page 10 of 19
Picture 3 demonstrates the process diagram documenting the public process for the processing of centralized buying: Picture 3: Process for the creation of a centralized buying - shown is the public process, which means the external view of the partners to the centralized buying 2.8 Selection of Process Type From the former explanation follows, that the purpose of the process picture is the most important selection criterion for the type of process representation: Executable processes are used for the clarification of control and information flows (either in case of detailed organizational documentations or for preparation of workflow automation) Private processes are used for the internal management view to the logic of the processes Public processes are used to clarify the logic of interaction with external partners Dipl.-Ing. Walter Abel Management Consulting Page 11 of 19
3. Collaborations Collaborations also have been part of previous versions of BPMN. A collaboration illustrates the interaction between different partners via information exchange. Thus a collaboration diagram contains participants shown as pools and information flows between these pools. In this case each partner representing pool holds the process the partner performs during the interaction. In our process of centralized buying the enterprise interacts with several suppliers. Within this interaction each partner performs his process. Information is sent to and received from the partner. The corresponding collaboration is shown in Picture 4: Picture 4: Process for the creation of a centralized buying - shown is the collaboration of partial processes The pool Supplier is characterized as multi instance participant by the three parallel lines at the bottom. This means that the information exchange is not only done with one supplier but with several of them. Each supplier is perfoming the modelled process and the enterprise exchanges information with each of them as shown. Multi instance participants are new with BPMN 2.0. The processes contained in the pools above are the same as in Picture 1. To improve clarity the symbols of the information events are skipped. Their meaning can be read from the depicted information flows. The complete collaboration starts with the requestor whose process starts with an undefined start event ( Demand ). This event has no cause within the process. It ocurres in case the requestor invokes the process. In contrary the processes of the other partners are starting with information flow receiving start events. Such an event ocurres when the respective message arrives to the partner. Dipl.-Ing. Walter Abel Management Consulting Page 12 of 19
Within BPMN information flows may be sent from tasks but also from events. Just as well tasks and events may be targets of information flows. In BPMN both is possible. An information flow receiving event defined that the process waits for the information. Sending a message requires active action by the participant, thus it is more or less connected with a task and only seldom with an event. Only the going out of a message without any activity may be modelled via a information sending event. This was used in the process of centralized buying, for instance the sending of the List of Requirements per email because the usage of a separate Task Send Request for Delivery Capability would have been less compact. BPMN provides two special types of tasks (no more detailed activities) for sending messages (type send ) and receiving messages (type receive ). These tasks may be used instead of the respective information events. At the other hand the information receiving event represents the waiting for the message very well, hence it is used in the presented model. 3.1 Black Box - Pools Within a collaboration diagram it is possible to skip the processes in one or more pools and just look to the information flows between the pools. These pools are represented as black boxes. The information flows start and end at the border of the respective pool. Picture 5 shows a combination where requestor and supplier are represented by black box pools, at the other hand the business manager and the purchasing agent are shown as white boxes with the formerly described public processes: Picture 5: Process for the creation of a centralized buying - shown is the collaboration of partial processes with black boxes Dipl.-Ing. Walter Abel Management Consulting Page 13 of 19
It is easy to recognize that here the focus is lying on the information exchange between the partial processes. This can go as far as that a complete black box construct is used and only the information flows are documented. An example is the distributed process development where the process owners of the partial processes model their flows within the framework of predefined information flows. Picture 6: Process for the creation of a centralized buying - shown is the collaboration of partial processes completely with black boxes Dipl.-Ing. Walter Abel Management Consulting Page 14 of 19
4. Choreographies The presentation of processes and collaborations was possible in former BPMN versions also. They only have been extended by some additional constructs in BPMN 2.0. The explicit modelling of choreographies via related diagrams ic completely new. A choreography is the sequence of message exchanges between different partners typically in business - to - business scenarios. The difference to the collaboration is that within a collaboration the sequence of information flows is important while in a collaboration this sequence is described independent from the processes. From a black box description like in picture 5 and 6 one can read which messages are exchanged by the partners, but not the exact sequence or conditional information flows respective loops of the information flow. So for instance in our example it is not shown that after arrival of the purchase requisition at the business manager s exactly one of two possible messages is sent. Furthermore it is not shown that after denial of the purchase requisition the complete flow is finished. To document the logic of the sequence flow there are two possibilities existing. At one hand side it is feasible to document al least the public process of one of the partners involved in the information exchange like in picture 5. At the other hand side it is possible to use a choreography diagram: Picture 7: Process for the creation of a centralized buying - choreography to document the logic of sequence Each activity within the choreography is triggered by one partner by sending the first message. This partner is documented in the light stripe (usually at the top) of the activity symbol. The other partners are documented in the dark stripe (usually at the bottom) of the activity symbol. Whether the light stripe is on top and the dark stripe is at the bottom of the activity symbol or vice versa is just convention but should be consistent within a model. In addition if a collaboration is modelled it makes sense to take the vertical order of the pools as basis for the convention. Choreography activities with more than one partner are not part of our example. For this purpose it is possible to define multiple partner fields in the activity symbol. Only one is light as only one partner can trigger the sequence. The choreography activity Check Delivery Capability carries a multiple symbol as it is executed multiple. As the related partner is also shown as multiple the message exchange is done with each supplier separately. A sequence flow is defined for the choreography activities within choreography diagrams. Its modelling follows the same rules like for the sequence flow within normal processes but some elements of process modelling do not make sense in choreography modelling. Hence they are not allowed. As an example there are no message events in the normal sequence flow as message exchange is part of the choreography activities per definition. Thus an event based gateway is followed by a choreography activity and not by an event. In this case the path is selected which choreography activity is started by the triggering message at first. Dipl.-Ing. Walter Abel Management Consulting Page 15 of 19
If one wnts to know what messages are exchanged in the choreography activities they can be represented by the letter symbols and connected with the respective partner field: Picture 8: Process for the creation of a centralized buying - choreography to document the logic of sequence including messages 4.1 Usage of Choreographies and Collaborations As presented above it is possible to document the content of choreographies by usage og collaborations also. There are some reasons to use choreographies despite: Choreographies document the information exchange independent from the partner processes. Hence they are a better basis for agreements and contracts between partners. The required process interfaces are to be defined in an easy way. Thus they are the basis for creation and adaption of the processes for the partners to correctly fulfil the agreed interaction. The sequence of the information exchange including branching is more obvious. Within a collaboration this information has to be retrieved from the involved partner processes. Especially in complex environments the choreography is much clearer as a collaboration with at least one public process (compare e.g. picture 7 to picture 4). Choreographies can be documented by the usage of choreography subprocesses supporting a more compact documentation of complex flows. Especially within complex business - to - business scenarios choreography diagrams are useful e.g. in the context of electronic marketplaces or with the development of industry specific standards and rules for defined transactions between partners. If an enterprise documents its internal processes and wants to describe the message exchange with its partners a collaboration diagram is used. Dipl.-Ing. Walter Abel Management Consulting Page 16 of 19
5. Conversations Also the conversation diagram is new in BPMN 2.0. Simply spoken the conversation describes which message exchanges belong to gether. A problem with the exchange of messages is to assign the incoming message to the right process instance. In our example of centralized buying if the supplier receives an inquiry for delivery capability this has to know to which instance of the centralized buying process it refers. In most cases the supplier will have created more than one statement of delivery capability for different centralized buying orders. Normally within the order there is a reference to the inquiry so that it can be allocated to the correct purchasing case. In electronically supported processes it is important to define exactly how the information systems of the involved partners allocate the incoming messages to the correct process instance. This is known as correlation of messages belonging together. These messages belonging together need to carry a correlation key. Messages combined within the communication carry the same correlation key. Within the presented information the smallest amount of messages belonging together are called communication. A conversation consists of multiple communications: Picture 9: Process for the creation of a centralized buying - conversation for the presentation of message exchanges Besides communications also information flows are possible in conversation diagrams, processes and choreographies are not allowed. Conversations may be hierarchical. For instance the + symbol in the hexagon Order within picture 9 represents a sub conversation to be described by a separate conversation diagram (not shown here). As communications combine information flows a relation is existing between communications and information flows. This is not evident immediately within a BPMN diagram. It is task of the modeller to make this relation apparent in graphical representation. For instance it is possible to mark the information flows belonging to separate communications by means of grouping within collaboration and choreograpy diagrams. The exact definition of correlations and thus the modelling of conversations normally is not the focus of most of the BPMN modellers. In case of SOA platforms and process engines in the framework of cross company processes with complex partner interaction the documentation of conversations provides an useful overview about the total scenario. Even in cases where detailed documented correlation mechanisms are not the primary focus a conversation diagram provides a first overview of the overall context of the partner network. The communication of the partners related to defined cases is clearly represented. The following details can be modelled in choreography and collaboration diagrams. Dipl.-Ing. Walter Abel Management Consulting Page 17 of 19
6. Summary The possibilities of modelling of cross partner processes have been especially enhanced in BPMN 2.0 by the introduction of the choreography and conversation diagram. At one hand this is an enrichment, at the other hand it makes BPMN even more voluminous and complex. Additionally one situation can be modelled in different ways. Collaborations, choreographies and conversations are different views of the same topic - the exchange of messages between partners. It is not so easy to have an overview about the relation of these representations. Some criticism by the modellers is focused on that asking for a simple and clear notation. For the practical use this means that the fitting diagram type has to be selected for the respective modelling purpose. Besides this it is necessary to define which circumstances should be modelled how within the diagrams. For instance, if an enterprise wants to document and maintain their internal processes it makes sense to use normal process diagrams. For processes with dominant partner interaction collaboration diagrams are useful, representing the partners by black boxes. Two or more enterprises which want to build up a business - to - business integration should use choreography diagrams to specify the interaction to be supported by all partners. In case the partners afterwards develop their own processes to support this choreography they may embed this choreography into a collaboration diagram to ensure that their own processes support the agreed choreography correctly. Dipl.-Ing. Walter Abel Management Consulting Page 18 of 19
7. Sources Parts of this whitepapers are taken from the document: Kollaborationen, Choreographien und Konversationen in BPMN 2.0 - Erweiterte Konzepte zur Modellierung übergreifender Geschäftsprozesse by Prof. Dr. Thomas Allweyer Fachhochschule Kaiserslautern - University of Applied Sciences Fachbereich Informatik und Mikrosystemtechnik Amerikastraße 1 D - 66482 Zweibrücken with friendly permission of the author. Karl Czerny - Gasse 2/2/32 A - 1200 Vienna Phone: +43 (1) 92912 65 Fax: +43 (1) 92912 66 office@walter-abel.at www.walter-abel.at www.itsmprocesses.com Dipl.-Ing. Walter Abel Management Consulting Page 19 of 19