BPMN stands out from traditional process modeling notations in its breadth of potential use, by modelers and developers at widely different levels of technical skills. However, as a vendor-neutral standard intended for use across a broad range of tools and applications, BPMN does not specify a methodology. The spec does not even suggest best practices for how to use the notation effectively for any particular modeling purpose.
To fill this gap, BPMessentials provides a methodology for how to use the notation consistent with the philosophy of BPM, which conceptualizes business processes as a single end-to-end units. We show you how to organize your thinking about end to end processes, how to do top-down modeling using BPMN sub-processes, drilling down as needed to add detail, and then how to translate that thinking into the notation.
We show you how to use BPMN at 3 distinct levels:
1. Descriptive modeling, the kind most BPM consultants typically talk about — high-level, occasionally ignoring BPMN’s diagram validation rules, but easy to communicate across the organization, linked with a methodology for how to do it. Level 1 modeling requires understanding of fundamental concepts such as pools and lanes, tasks and subprocesses, and sequence flow, but not the complexities of BPMN’s various flow control and event patterns.
2. Analytical modeling, more detailed, showing all the steps, including the exception paths, required either to analyze process performance using simulation or to create detailed requirements for an IT implementation. Level 2 modeling requires understanding of BPMN’s various decision and merge patterns, events, and exception handling patterns. Level 2 diagrams must be both valid according to the rules in the BPMN spec, and organized effectively as hierarchical representations of the end to end business process.
3. Executable modeling, where BPMN is part of the excecutable process implementation. While this capability of BPMN is a major reason for its widespread adoption, modeling at this level is somewhat vendor tool-dependent, as most BPM Suites do not support all of the gateway and event types defined in the BPMN spec, and may offer their own proprietary extensions as well. Moreover, most tools ignore the BPMN spec’s implementation attributes, and instead provide equivalent implementation detail in tool-specific attributes of the model’s activities, gateways, and events. Level 3 diagrams thus typically impose additional validation constraints beyond those of the BPMN spec.