Process Modelling
Process modelling is the graphical representation of how a piece of work unfolds: the sequence of activities, the roles that carry them out and the decisions that steer their course, from trigger to result. The same reality can be drawn as a flowchart, in BPMN, as a UML activity diagram or as an IDEF/IGOE diagram, four notations that express the same small set of elements and are told apart by audience, domain, degree of formality and use. Setting the level of detail weighs as much as choosing the notation.
Goal
A process model is a standardised graphical model of the sequence of activities through which a piece of work is carried out. In its simplest form an event triggers it, a chain of activities follows, a result ends it; a richer form adds the data and materials that the activities consume and produce. The deliverable is a diagram, most often accompanied by a text that documents it.
The technique serves to bring an organisation into agreement on what it does. It describes the scope of a solution by showing the activities and actors it touches, it gives a piece of work a reading that an outside observer can follow without knowing the business, and it provides the base without which process analysis has nothing to measure. A current-state model, the as-is, builds a shared understanding of what happens today; a future-state model, the to-be, sets what one wants to reach. Both use the same elements and the same notation; only the point in the project and the question being asked differ.
Usage
When to use it
- Understanding a process before changing it: give every party the same picture of what actually happens.
- Framing the scope of a solution: show the activities and actors involved before eliciting requirements.
- Aligning stakeholders: reach explicit agreement on the current state or the target state.
- Preparing a process improvement: laying the process flat is the precondition of any measurement or comparison.
- Feeding an automation: give an execution engine the formal model it needs.
When not to use it
- The complexity lies in the decision logic: handle the rules separately with decision modelling.
- The question is about data structure: prefer a data model or a data flow diagram.
- A fast-moving, throwaway process: a maintained model will be stale before it is read, keep to a short text or a checklist.
The choice criterion
Since the four notations express the same vocabulary, what they let you say does not tell them apart: the choice turns on the audience the model must reach and the use it will serve. Four criteria settle it, and one alone is often enough.
The audience first: a non-technical reader follows a flowchart effortlessly, where a rich notation loses them. The domain next: a business process calls for an enterprise notation, a process that lives inside software calls for a design notation. The formality required: a quick alignment makes do with a sketch, a model that crosses organisational boundaries or drives a machine demands a precise, unambiguous notation. The use last: a model meant for discussion, a model meant for execution and a model meant to frame a scope do not ask for the same means.
Four notations cover almost every case, each with its own symbols, reading rules and worked examples. The flowchart is the simplest and most universally understood notation, the one you reach for first for a shared, low-ceremony picture. BPMN is the standard language, readable by business and technical stakeholders alike, able to describe internal or cross-organisational collaborative processes and to feed an automation. The UML activity diagram belongs to the software domain and serves when the process sits inside a design already expressed in UML. The IDEF/IGOE diagram establishes scope and boundaries, what enters, what guides the work, what comes out and what enables it, before the sequence is drawn out.
You'll find more detail in our BPMN tutorial.
| Your intent and your audience | Notation | Why it fits |
|---|---|---|
| Obtain a shared, low-formality picture for a non-technical audience and agree on what the process is. | Flowchart | The simplest and most widely read notation; swimlanes commonly add the roles. |
| A precise model, readable by business and technical staff alike, possibly cross-organisational or meant for execution. | BPMN | Standard language, rich in events and decision points; pools and swimlanes separate the actors; it can feed an automation engine. |
| A process set inside a software design already described in UML. | UML activity diagram | A UML use-case-realisation diagram; partitions for responsibility, synchronisation of parallelism. |
| Establish the scope and boundaries of a process before detailing its sequence. | IDEF / IGOE | Frames the inputs, guides, outputs and enablers; built for the outline, not the detailed flow. |
Levels of representation
The choice of notation in fact commits you to less than it seems. One process can be drawn at several levels of detail, each serving a different viewpoint, and setting that level weighs as much as choosing the notation. This is often where a model misses its target: too high a level hides the operational problems, too fine a level becomes unreadable and no one can validate it any more.
| Level | What you see | What it serves |
|---|---|---|
| Context / enterprise | The process as a whole and its links with neighbouring processes, without the detail of the steps. | A general understanding and the process's place in the organisation. |
| Operational | The fine-grained activities, the exceptions and the alternative paths. | Analysing the real work, spotting the friction points, preparing an improvement. |
| System | The sequence formalised to the point where a machine can simulate or execute it. | Serving as the base for a simulation or an automation. |
A shared vocabulary in four alphabets
If the choice commits you to little, it is because the notations differ in their symbols, not in what they describe. BABOK lists the elements each of them expresses, and they are always the same. An activity is a step in the process, which can itself be decomposed into a subprocess. An event is a zero-duration occurrence that triggers, interrupts or ends the flow. The directional flow is the logical sequence that links the steps, drawn in the reading direction. A decision point splits the flow into exclusive or parallel paths or merges them. A link connects the model to another process model. A role designates the person or group involved and attaches to the organisation model.
This closeness to the ordinary intuition of a sequence of actions explains why modelling speaks to stakeholders with no training and why moving from one notation to another remains possible. The model also has a value the drawing does not show: it enforces consistent labels, it makes responsibilities and hand-overs visible, and it brings out groups no one had thought to consult.
Pitfalls to avoid
Three faults lie in wait whatever notation is chosen. Mixing decision logic into the flow first: when every business rule becomes a branch, the model swells to the point of unreadability, whereas the rules hold together better on their own. Over-decomposition next, that model so detailed no single person understands it, validates it or signs it off. Staleness last: in a moving environment, a model that is only documentation drifts from the real process and becomes an archive no one consults any more. To these three is added a cultural resistance, modelling being seen in some IT quarters as an old, document-heavy approach for which no time is set aside; it is defused by holding the model at the right level and tying it to a decision it serves.
AI considerations
A language model is useful at several steps of this technique. It drafts a first pass from existing material: the notes of an interview, a written procedure or a standard operating procedure become a candidate flow that an analyst corrects faster than starting from a blank page. It flags exception paths a first human pass often neglects, the rejection, the cancellation, the missed deadline. It harmonises activity labels across several models of the same domain, and it translates a model from one notation into another when the audience changes.
Its limit is a business one and it is not negotiable. The machine infers a flow from what it is given to read, along with the source's errors and silences; it does not know what the organisation actually does when no document says so, and that is exactly where the detours and exceptions that make the as-is model worthwhile are hidden. Validating that a model reflects the real work falls to the people who perform it. Choosing the right level and the right notation for a given audience remains a judgement, as does discarding a branch the AI has invented that no rule supports. Every proposal from the machine is a draft submitted to the stakeholders.
Cost
The effort depends on the notation and the level more than on the technique itself. A framing flowchart costs a few hours; an executable, maintained BPMN model costs a great deal and for a long time.
| Phase | Level | Justification |
|---|---|---|
| Preparation | Low to medium | Gather the people who know the process and collect the existing procedures. The current state mainly needs access to the right people. |
| Execution | Low to high | One session is enough for a framing flowchart; a detailed operational model, with its exceptions and alternative paths, calls for several workshops and validation by the actors. |
| Documentation | Medium to high | A discussion-support model is thrown away after use. A model that must remain the mirror of the process or drive its execution is updated at every change. |
Tooling
The tooling follows the ambition of the model and the notation chosen. A whiteboard and repositionable stickies remain the fastest way to make a team talk and to lay out a current state. A generic diagramming tool produces a clean, versionable model, enough for a flowchart or a first BPMN pass. A specialised BPM suite becomes necessary when the model must be precise, tied to a process repository and kept over time, with notation validation, simulation and version management. The notation constrains the tool: a BPMN model meant for execution presupposes an engine able to interpret it, which a plain drawing editor does not replace.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.35 Process Modelling: the definition of the technique and the enumeration of the elements common to the notations.
- ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), Process Modeling knowledge area: the body of knowledge that carries authority on process modelling and its notations, including the IGOE lineage.
- OMG, Business Process Model and Notation (BPMN) 2.0.2: the specification that defines BPMN.
- OMG, Unified Modeling Language (UML) Specification: the specification that defines the activity diagram.
- NIST, FIPS PUB 183, Integration Definition for Function Modeling (IDEF0): the federal standard that defines IDEF0 function modelling.