´cnico Nacion Instituto Instituto Polit Politecnico e Nacional al
´ mputo Escue Escuela la Superi Superior or de Computo o Software Software Engineering
Business Process Model and Notation Student: Christian Miguel
Teacher: M. C. Idalia Maldonado
´ ndez Mej´ Hernandez a ıa
Castillo
February 7, 2018
Contents 1 Objective
2
2 Content 2.1 Scope . . . . . . . . . . . . . . . . . . . . . 2.2 Purpose and benefits . . . . . . . . . . . . . 2.3 Uses of BPMN . . . . . . . . . . . . . . . . 2.3.1 Private (Internal) Business Processes 2.3.2 Public Processes . . . . . . . . . . . 2.3.3 Collaborations . . . . . . . . . . . . . 2.3.4 Choreographies . . . . . . . . . . . . 2.3.5 Conversations . . . . . . . . . . . . . 2.4 BPMN Diagram Symbols and Notation . . .
2 2 2 3 3 4 4 4 5 6
3 Conclusions
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
9
1
1
Objective
Understand the operation of the standard Business Process Model and Notation (BPMN) for the elaboration of diagrams that describe the behavior of the processes involved in a business, as well as to know each one of the components that compose a BPMN diagram and its way of use.
2
Content Abstract
A standard Business Process Model and Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Furthermore, the graphical notation will facilitate the understanding of the performance collaborations and business transactions between the organizations. This will ensure that businesses will understand themselves and participants in their business and will enable organizations to adjust to new internal and B2B business circumstances quickly.
2.1
Scope
The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation. Another goal, is to ensure that XML languages designed for the execution of business processes, can be visualized with a business-oriented notation. This specification represents the amalgamation of best practices within the business modeling community to define the notation and semantics of Collaboration diagrams, Process diagrams, and Choreography diagrams. The intent of BPMN is to standardize a business process model and notation in the face of many different modeling notations and viewpoints. In doing so, BPMN will provide a simple means of communicating process information to other business users, process implementers, customers, and suppliers.
2.2
Purpose and benefits
At a high level, BPMN is targeted at participants and other stakeholders in a business process to gain understanding through an easy-to-understand visual representation of the steps. At a more involved level, it’s targeted at the people who will implement the process, giving sufficient detail to enable precise implementation. It provides a standard, common language for all stakeholders, whether technical or non-technical: business analysts, process participants, managers and technical developers, as well as external teams and consultants. Ideally, it bridges the gap between process intention and implementation by providing sufficient detail and clarity into the sequence of business activities. The 2
diagramming can be far easier to understand than narrative text would be. It allows for easier communication and collaboration to reach the goal of an efficient process that produces a high-quality result. It also helps with communication leading to XML documents needed to execute various processes.
2.3
Uses of BPMN
Business Process modeling is used to communicate a wide variety of information to a wide variety of audiences. BPMN is designed to cover many types of modeling and allows the creation of end-to-end Business Processes. The structural elements of BPMN allow the viewer to be able to easily differentiate between sections of a BPMN Diagram. There are three basic types of sub-models within an end-to-end BPMN model: 1. Processes (Orchestration), including: •
Private non-executable (internal) Business Processes
•
Private executable (internal) Business Processes
•
Public Processes
2. Choreographies 3. Collaborations, which can include Processes and/or Choreographies •
2.3.1
A view of Conversations
Private (Internal) Business Processes
Private Business Processes are those internal to a specific organization. These Processes have been generally called workflow or BPM Processes. There are two types of private Processes: executable and non-executable. Of course, during the development cycle of the Process, there will be stages where the Process does not have enough detail to be “executable.” A non-executable Process is a private Process that has been modeled for the purpose of documenting Process behavior at a modeler-defined level of detail. Thus, information needed for execution, such as formal condition Expressions are typically not included in a non-executable Process. If a swimlanes-like notation is used (e.g., a Collaboration) then a private Business Process will be contained within a single Pool. The Process flow is therefore contained within the Pool and cannot cross the boundaries of the Pool. The flow of Messages can cross the Pool boundary to show the interactions that exist between separate private Business Processes.
Figure 1: Example of a private Business Process
3
2.3.2
Public Processes
A public Process represents the interactions between a private Business Process and another Process or Participant. Only those Activities that are used to communicate to the other Participant(s) are included in the public Process. All other “internal” Activities of the private Business Process are not shown in the public Process. Thus, the public Process shows to the outside world the Message Flows and the order of those Message Flows that are needed to interact with that Process. Public Processes can be modeled separately or within a Collaboration to show the flow of Messages between the public Process Activities and other Participants.
Figure 2: Example of a public Process
2.3.3
Collaborations
A Collaboration depicts the interactions between two or more business entities. A Collaboration usually contains two or more Pools, representing the Participants in the Collaboration. The Message exchange between the Participants is shown by a Message Flow that connects two Pools (or the objects within the Pools). The Messages associated with the Message Flows can also be shown. The Collaboration can be shown as two or more public Processes communicating with each other. With a public Process, the Activities for the Collaboration participants can be considered the “touch-points” between the participants. The corresponding internal (executable) Processes are likely to have much more Activity and detail than what is shown in the public Processes. Or a Pool may be empty, a “black box.” Choreographies may be shown “in between” the Pools as they bisect the Message Flows between the Pools. All combinations of Pools, Processes, and a Choreography are allowed in a Collaboration.
2.3.4
Choreographies
A self-contained Choreography (no Pools or Orchestration) is a definition of the expected behavior, basically a procedural contract, between interacting Participants. While a normal Process exists within a Pool, a Choreography exists between Pools (or Participants). The Choreography looks similar to a private Business Process since it consists of a network of Activities, Events, and Gateways. However, a Choreography is different in that the Activities are interactions that represent a set (1 or more) of Message exchanges, which involves two or more Participants. In addition, unlike a normal Process, there is no central controller, responsible entity or observer of the Process.
4
Figure 3: An example of a Collaborative Process
Figure 4: An example of a Choreography
2.3.5
Conversations
The Conversation diagram is a particular usage of and an informal description of a Collaboration diagram. However, the Pools of a Conversation usually do not contain a Process and a Choreography is usually not placed in between the Pools of a Conversation diagram. A Conversation is the logical relation of Message exchanges. The logical relation, in practice, often concerns a business object(s) of interest, e.g., “Order,” “Shipment and Delivery,” or “Invoice.” Message exchanges are related to each other and reflect distinct business scenarios. For example, in logistics, stock replenishments involve the following type scenarios: creation of sales orders; assignment of carriers for shipments combining different sales orders; crossing customs/quarantine; processing payment and investigating exceptions. Thus, a Conversation diagram, shows Conversations (as hexagons) between Participants (Pools). This provides a “bird’s eye” perspective of the different Conversations that relate to the domain.
5
Figure 5: An example of a Conversation diagram
2.4
BPMN Diagram Symbols and Notation
Like flowcharts, BPMN diagrams use a set of standard symbols. Each shape has a specific meaning and business context where it’s most appropriate. BPMN depicts these four element types for Business Process Diagrams: 1. Flow objects: events, activities and gateways 2. Connecting objects: sequence flow, message flow, association 3. Swim lanes: pool or lane 4. Artifacts: data object, group, annotation
Events A trigger that starts, modifies or completes a process. Event types include message, timer, error, compensation, signal, cancel, escalation, link and others. They are shown by circles containing other symbols based on event type. They are classified as either “throwing” or “catching,” depending on their function.
Figure 6: Event notation
Activity A particular activity or task performed by a person or system. It’s shown by a 6
Figure 7: Activity notation rectangle with rounded corners. They can become more detailed with sub-processes, loops, compensations and multiple instances.
Gateway Decision point that can adjust the path based on conditions or events. They are shown as diamonds. They can be exclusive or inclusive, parallel, complex, or based on data or events.
Figure 8: Fateway notation
Sequence Flow Shows the order of activities to be performed. It is shown as a straight line with an arrow. It might show a conditional flow, or a default flow.
Figure 9: Sequence flow notation 7
Message Flow Depicts messages that flow across “pools,” or organization boundaries such as departments. It shouldn’t connect events or activities within a pool. It is represented by a dashed line with a circle at the start and an arrow at the end.
Figure 10: Message flow notation
Association Shown with a dotted line, it associates an artifact or text to an event, activity or gateway.
Figure 11: Association notation
Pool and Swim Lane A pool represents major participants in a process. A different pool may be in a different company or department, but still involved in the process. Swim lanes within a pool show the activities and flows for a certain role or participant, defining who is accountable for what parts of the process.
Figure 12: Pool and Swim Lane notation
Artifact Additional information that developers add to bring a necessary level of detail to the diagram. There are three types of artifacts: data object, group or annotation. A data object shows what data is necessary for an activity. A group shows a logical grouping of activities but doesn’t change the diagram’s flow. An annotation provides further explanation to a part of the diagram. Example The Pizza Collaboration 8
Figure 13: Artifact notation
3
Conclusions
The research showed the importance of having a methodology to develop process diagrams with the correct elements, as well as the importance of using each component to elaborate clear diagrams that can be understood by all the participants in the business process.
9
References [BPMN Specification] “BPMN Specification - Business Process Model and Notation”, Bpmn.org, 2018. [Online]. Available: http://www.bpmn.org/ Accessed: 07- Feb2018. [BPMN Quick Guide] “View the BPMN Quick Guide - BPMN Quick Guide”, BPMN Quick Guide, 2018. [Online]. Available: http://www.bpmnquickguide.com/viewbpmn-quick-guide/. Accessed: 07- Feb- 2018. [The Pizza Collaboration] “The Pizza Collaboration - BPI - The destination for everything process related”, BPI - The destination for everything process related, 2018. [Online]. Available: https://www.businessprocessincubator.com/content/the-pizzacollaboration/. Accessed: 07- Feb- 2018. [What is] “What is Business Process Modeling Notation”, Lucidchart, 2018. [Online]. Available: https://www.lucidchart.com/pages/bpmn. Accessed: 07- Feb- 2018.
10
Figure 14: The Pizza Collaboration
11
