Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes in a business process model.
Initially developed by the Business Process Management Initiative (BPMI), BPMN has been maintained by the Object Management Group (OMG) since the two organizations merged in 2005. Version 2.0 of BPMN was released in January 201, when the name was amended to Business Process Model and Notation to reflect the introduction of execution semantics, which were introduced alongside the existing notational and diagramming elements. Though it is an OMG specification, BPMN is also ratified as ISO 19510. The latest version is BPMN 2.0.2, published in January 2014.
Overview
Business Process Model and Notation (BPMN) is a standard for business process modeling that provides a graphical notation for specifying business processes in a Business Process Diagram (BPD), based on a flowcharting technique very similar to activity diagrams from Unified Modeling Language (UML).The objective of BPMN is to support business process management, for both technical users and business users, by providing a notation that is intuitive to business users yet able to represent complex process semantics. The BPMN specification also maps the notation graphics and the underlying constructs of execution languages, particularly Business Process Execution Language (BPEL).
BPMN has been designed to provide a standard notation that is readily understandable by all business stakeholders, including business analysts, technical developers, and business managers. BPMN can therefore be used to support the generally desirable aim of all stakeholders on a project adopting a common language to describe processes, helping to avoid communication gaps that can arise between business process design and implementation.
BPMN is one of several business process modeling language standards used by modeling tools and processes. At the same time, the current variety of languages may suit different modeling environments, and some advocate for developing or emerging a single, comprehensive standard combining the strengths of different existing languages. It is suggested that, in time, this could help to unify the expression of basic business process concepts (e.g., public and private processes, choreographies) as well as advanced process concepts (e.g., exception handling, transaction compensation).
Two new standards, using a similar approach to BPMN have been developed, addressing case management modeling (Case Management Model and Notation) and decision modeling (Decision Model and Notation).
Topics
Scope
BPMN is constrained to support only the modeling concepts applicable to business processes. Other types of modeling organizations do for non-process purposes are out of the scope of BPMN. Examples of modeling excluded from BPMN are:
- Organizational structures
- Functional breakdowns
- Data models
In addition, while BPMN shows the flow of data (messages), and the association of data artifacts to activities, it is not a data flow diagram.
Elements
BPMN models are expressed by simple diagrams constructed from a limited set of graphical elements. For both business users and developers, they simplify understanding of business activities’ flow and process. BPMN’s four basic element categories are: Flow objects, events, activities, gateways connecting objectsSequence flow, message flow, association swim lanes pool, lane, Dark PoolArtifactsData object, group, annotation
These four categories enable the creation of simple business process diagrams (BPDs). BPDs also permit making new flow objects or artifacts to make the diagram more understandable.
Flow objects and connecting objects
 |  |  |  |
Flow objects are the main describing elements within BPMN, and consist of three core elements: events, activities, and gateways. An Event Event is represented with a circle and denotes something that happens (compared with an activity, which is something that is done). Icons within the circle denote the type of event (e.g., an envelope representing a message or a clock representing time). Events are also classified as Catching (for example, if catching an incoming message starts a process) or Throwing (such as throwing a completion message when a process ends). Start events act as a process trigger, indicated by a single narrow border, and can only be Catch, so it is shown with an open (outline) icon. Intermediate event Represents something that happens between the start and end events; is indicated by a double border, and can Throw or Catch (using solid or open icons as appropriate). For example, a task could flow to an event that throws a message across to another pool, where a subsequent event waits to catch the response before continuing. The end event represents the result of a process, indicated by a single thick or bold border, and can only Throw, so it is shown with a solid icon. An activity is represented with a rounded-corner rectangle and describes the kind of work which must be done. An activity is a generic term for work that a company performs. It can be atomic or compound. Task A
Flow objects are connected using Connecting objects of three types: sequences, messages, and associations. Sequence FlowA Sequence Flow is represented with a solid line and arrowhead and shows in which order the activities are performed. The sequence flow may also have a symbol at its start; a small diamond indicates one of several conditional flows from an activity, while a diagonal slash indicates the default flow from a decision or activity with conditional flows. Message FlowA Message Flow is represented with a dashed line, an open circle at the start, and an open arrowhead at the end. It tells us what messages flow across organizational boundaries (i.e., between pools). A message flow can never be used to connect activities or events within the same pool. Association is represented with a dotted line. It is used to associate an Artifact or text with a Flow Object. It can indicate some directionality using an open arrowhead (toward the artifact to represent a result, from the artifact to represent an input, and both to indicate it is read and updated). No directionality is used when the Artifact or text is associated with a sequence or message flow (as that flow already shows the direction).