Fundamentals of BPM (2018) — Ch. 3: Essential Process Modeling

Chapter deep-dive into sources/2018-dumas-fundamentals-of-bpm §3, the canonical introduction to BPMN in the context of conceptual process modelling. Sets the foundation for Ch. 4 (Advanced) and Ch. 5 (Discovery). Back-links to the meta source page.

3.1 First Steps with BPMN

Three basic concepts (§3.1)

Concept	BPMN visual	Meaning
Event	Circle (thin border = start, thick = end, double = intermediate)	Something that happens instantaneously (e.g., invoice received)
Activity	Rounded rectangle	Unit of work with duration (e.g., pay invoice)
Arc / Sequence flow	Solid arrow with full arrow-head	Logical relation: A is followed by B

Most modelling needs covered by a small subset of BPMN's 100+ symbols. The chapter introduces symbols gradually by example.

Token semantics (§3.1, see also concepts/token-semantics)

Tokens reify the Petri-net marking inside BPMN:

A token is created at a start event when an instance begins.
It flows along sequence flows.
It's destroyed at an end event.
The state of a process instance = distribution of its tokens (its marking).
Multiple instances run independently — visualised as different-coloured tokens.

Naming conventions (§3.1)

Stricter and more granular than the concepts/7pmg G6 summary:

Activities — verb-object (imperative + business object):

Approve order ✅
Noun may be preceded by an adjective: Issue driver license ✅
Verb may be followed by an adverbial clause: Renew driver license via offline agencies ✅
Max 5 words excluding prepositions and conjunctions, to keep labels readable.
Replace generic verbs (to make, do, perform, conduct) with specific verbs that capture the activity's specifics.
Avoid words like process or order used as both verb and noun within one model — pick one part of speech and stick to it.

Events — noun + past-participle (state):

Invoice emitted ✅, Urgent order sent ✅
Past participle indicates something has just happened.

Processes — noun, optionally with adjective:

Loan origination, order fulfillment, claim handling.
Obtain by nominalising the verb of the main process action: "fulfill order" → "order fulfillment".
Hyphenated forms also acceptable: order-to-cash, procure-to-pay.

Capitalisation:

First word of activity / event labels capitalised.
Process names typically not capitalised (order-to-cash, not Order-to-Cash).

Gateway labels: see §3.2.1 — labels on (X)OR-splits should be avoided; use explicit conditions on outgoing arcs.

Mapping, Abstraction, Purpose (§3.1, sidebar)

A model has three defining properties:

Mapping — correspondence to a real-world phenomenon.
Abstraction — what details are omitted.
Purpose — what determines which details to omit.

Essentially, all models are wrong, but some are useful. — George E.P. Box

The target audience determines purpose. A timber model of a building serves a prospective buyer; a blueprint serves an electrical engineer. Same building, different models, different abstractions, different audiences.

A foundational distinction Dumas makes explicit:

Aspect	Conceptual model	Executable model
Purpose	Organisational design	Application system design
Audience	Process owners, business analysts, participants	System engineers, solution architects, developers
Built by	Process analysts	Technical staff
Contents	Activities, events, gateways, lanes — no IT details	Plus data types, data mappings, service tasks, system interfaces
Used for	Discovery, communication, analysis, redesign basis	Software development blueprint, BPMS deployment

The same business process may need both: a conceptual model for stakeholder alignment and an executable model derived from it for automation. Chapter 10 of the Dumas book covers the conceptual → executable transition.

3.2 Branching and Merging

Activities/events are not necessarily sequential. BPMN models alternative and concurrent execution via gateways (diamond shape).

Gateway type	Outgoing semantic
Split	One incoming arc, ≥2 outgoing arcs — diverges flow
Join	≥2 incoming arcs, one outgoing arc — converges flow

3.2.1 Exclusive Decisions (XOR)

Used to model mutually exclusive alternatives.

XOR-split: routes the incoming token to exactly one outgoing branch based on conditions. Marker: empty diamond or "X".
XOR-join: passthrough — forwards each arriving token to its output. Acts as merge for previously-XOR-split branches.

Rules:

Annotate each outgoing arc with the condition that selects it.
Conditions must be mutually exclusive — only one can be true at any time.
Provide a default flow (oblique cut on the arrow) for the "otherwise" case in case all conditions are false.
Always complete the model with an end event, even if "obvious".

Example (Fig 3.4): invoice checking yields three mutually exclusive outcomes — no mismatches (post invoice), correctable mismatches (re-send), uncorrectable mismatches (block). Three branches from XOR-split, merged at XOR-join, then Park invoice completes.

3.2.2 Parallel Execution (AND)

Used when two or more activities have no order dependency and can be performed concurrently.

AND-split: generates N tokens, one for each outgoing branch — all branches execute in parallel.
AND-join: synchronises — waits for one token on every incoming arc, then merges into a single outgoing token.

Marker: diamond with "+".

Example (Fig 3.5): airport security check splits into "pass personal screening" + "pass luggage screening" in parallel; AND-join waits for both before "proceed to departure".

Multiple end events (§3.2.2): a model can have multiple end events, each capturing a distinct outcome (Order fulfilled vs Order rejected). BPMN uses implicit termination semantics: an instance completes only when every token reaches an end event — not just the first one.

Multiple start events: each captures a different trigger (e.g., Purchase order received vs Revised order received). Instance is initiated by whichever start event fires first.

3.2.3 Inclusive Decisions (OR)

For situations where one or more branches can be taken — the conditions need not be mutually exclusive.

OR-split: generates k tokens (1 ≤ k ≤ N), one for each branch whose condition is true.
OR-join: synchronising merge — waits for tokens from all active incoming branches, then merges into one.

Marker: diamond with "O".

Why OR is hard: the OR-join must reason about which incoming branches will eventually deliver a token (the active branches) — those that do not require global reasoning over future model behaviour. This is the source of OR-join semantic paradoxes flagged in concepts/7pmg G5.

Heuristic for join-type selection (§3.2.3):

Start with an XOR-join, next try an AND-join, and if both gateways lead to incorrect models use the OR-join which will work for sure.

In other words: prefer XOR (passthrough; works for mutually-exclusive branches), then AND (synchronisation; works for fully-parallel branches), and only fall back to OR when neither fits — because OR is the most expressive but also the most confusing.

Example (Fig 3.10): order distributed across two warehouses. Sub-orders sent to whichever warehouses contain relevant products (might be one, the other, or both). OR-split fires k branches; OR-join waits for all active branches before Register order.

Shorthand notations

Two abbreviations:

XOR-join can be omitted before an activity or event when the join is just a merge of mutually-exclusive branches. The incoming arcs flow directly into the next element.
AND-split can be omitted after an activity or event when launching parallel branches. Outgoing arcs emanate directly from the predecessor.

3.3 Business objects and resources (chapter map; not deep-dived here)

Pools, lanes, data objects, message flows. See frameworks/bpmn for the element catalogue and syntheses/bpmn-modelling-practical-guide §10 for builder-level rules.

3.4 Process decomposition (chapter map; not deep-dived here)

Sub-processes (embedded vs reusable / call activities), decomposition criteria, naming hierarchical models. See syntheses/bpmn-modelling-practical-guide §8.

Mode	Examples	Notes
Pen & paper	—	Initial sketch only; no systematic sharing
Haptic	Post-its, brown paper, sticky notes, tactile BPMN tiles	For workshops; high engagement
Single-user general	Microsoft Visio (BPMN stencil)	Drawing tool — exports to image, not BPMN XML
Single-user specialised	Bizagi Modeler, BOC ADONIS:CE, ARIS Express, Camunda Modeler	BPMN-native; varies in soundness checking
Multi-tenant	BOC ADONIS NP, IBM BlueWorks Live, Software AG ARIS, Signavio Process Manager	Shared repository, collaborative; cloud-based often
Open-source platform	Apromore	Process analytics + modelling

Critical: validate that your tool exports BPMN 2.0 XML. Visio and similar produce drawings, not models — downstream tooling integration is impossible.

Chapter takeaways for the practitioner

Master the core 5 gateways (XOR split/join, AND split/join, OR split/join, plus event-based — covered in Ch. 4) before adventuring into the rest of BPMN's symbol set.
Tokens are the right mental model for reasoning about gateway behaviour, soundness, and runtime.
Naming conventions matter empirically — see also sources/2010-mendling-reijers-vanderaalst-7pmg G6 for the experimental evidence behind verb-object labels.
Pick conceptual vs executable up front — different audiences, different content, different tools.
OR-joins are tempting and rarely worth it — the join-type heuristic (XOR → AND → OR) is the modeller's safety net.

Connections

Concepts: concepts/token-semantics · concepts/process-model-quality · concepts/7pmg · concepts/soundness · concepts/deadlock · concepts/lack-of-synchronization · concepts/block-structure Frameworks: frameworks/bpmn Sister chapter: sources/2018-dumas-fundamentals-of-bpm-ch5-discovery (Ch. 5 — Process Discovery, including §5.4 Quality Assurance) Meta source: sources/2018-dumas-fundamentals-of-bpm Practical synthesis: syntheses/bpmn-modelling-practical-guide (incorporates Ch. 3 + Ch. 5 + 7PMG into a builder's guide)

Open follow-ups

Ch. 4 deep-dive — Advanced Process Modeling (typed events, exceptions, boundary events, compensation, event sub-processes). Currently referenced-not-deep-dived.
Ch. 3 §3.3 + §3.4 deep-dive — Business objects/resources + process decomposition. Currently summarised in frameworks/bpmn and syntheses/bpmn-modelling-practical-guide but not as a dedicated source page.