Flowchart

Goal

The flowchart makes a process visible and negotiated at the lowest possible cost. Its product is a shared picture of what happens, step by step and of where the work branches, drawn fast enough to be born on the whiteboard, in the room, with the people who do the work. Process modelling makes it its entry-level member, which is a quality: universal legibility and near-zero cost are its reason for being.

Three uses carry it. Capturing a current state when the task under study abounds in decisions and alternative paths, where a picture of steps and tests goes faster than a text. Framing a target state during an improvement effort. Building consensus with a non-technical audience, because the deliverable is alignment itself: it bounds what the process is and it gets the room to agree. The diamond holds a place of its own here: it poses a binary question decided at the very point where it is drawn, whereas the diamonds of BPMN and the UML activity diagram merely route a decision settled upstream.

Usage

When to use it

• Investigating a decision-rich task: the situation abounds in choices and alternative paths, which a picture of steps and tests captures faster than a text.
• Aligning a non-technical audience: the room has no training in modelling and needs to agree on what the process is.
• Sketching a current or target state at low cost: with no tooling budget, a whiteboard or a general-purpose drawing tool is enough.
• Documenting a procedure with a simple nominal path: an operational sequence with a few binary branches, where formal semantics would be excessive.

When not to use it

• The process crosses an organisational boundary between independent participants or must run in an engine: move to BPMN.
• True concurrency, guarded edges or the realisation of a use case within a single system: move to the UML activity diagram.
• The question is not the sequence but what constrains and performs a function: move to IDEF / IGOE.

Description

A symbol set where the shape carries the meaning

The vocabulary fits in a handful of shapes, and it is their silhouette that carries the meaning. The ISO 5807 standard fixes this correspondence: the oval, or stadium, is a terminator, start or end; the plain rectangle is a step; the diamond is a decision; the parallelogram is an input or an output; the rectangle with a wavy bottom edge is a document, a receipt, a payslip; the rectangle with double vertical side bars is a sub-process detailed in its own model; a small circular connector marks where the flow resumes on another sheet. The arrows, solid and with a solid head, carry the sequence. BABOK, for its part, lists the elements of a process model, the activity, the event, the directional flow, the decision point, the link and the role; it is the standard that makes the parallelogram an input and the wavy box a document.

The diamond is the test

A flowchart diamond poses a binary question, "amount over CHF 1'000?", with exactly two labelled exits, yes and no. The decision is made at the diamond: this is the flowchart's own semantics, and it is what sets it apart from BPMN and the UML activity diagram, whose diamonds merely route a decision settled at the preceding step. This is a capability, the most recognisable of the notation: the branching logic reads on the drawing, at the point where it operates. A diamond with three exits or more is a switch and the sign that the logic is a business rule that would be better taken out of the flow.

Swimlanes on a flowchart

A flowchart accepts swimlanes: a partitioned band, horizontal or vertical, groups the activities carried by a role, and crossing its boundary shows responsibility passing to another. The BPM CBOK is explicit, "swim lanes are not a distinct notation" but a notational addition grafted onto most systems, the flowchart among them. What BPMN adds is therefore the message-flow semantics across a participant's boundary: a flowchart lane groups roles within one and the same organisation, it does not make two independent entities talk to each other.

You'll find more detail in our BPMN tutorial.

Building a flowchart

Construction follows a stable order. Fix the scope and the level first, by naming the process, the business event that triggers it and its outcome, then by choosing the grain, a high-level model builds consensus, a fine-grained model supports implementation. A flowchart is flat, a single level per diagram, with a connector where a segment continues on another sheet. Open and close on a terminator, the simplest model being trigger, sequence of activities, outcome. Lay down the sequence of activities as rectangles in reading order, keeping the nominal path straight and legible. Place the decisions as binary diamonds. Add the specialised shapes where they carry meaning, parallelogram, document, sub-process. Validate, finally, with the people who do the work, in an interview or a focus group: the value of a flowchart is the agreement it produces, and a model never confronted with the real work is merely decoration.

A few drifts lie in wait, and they are prevented at the drawing. Symbol drift: because the shapes are simple and, in practice, loosely standardised, organisations invent house symbols, and the model loses the universal legibility that is its only advantage; sticking to the ISO 5807 vocabulary preserves it. The flat-model trap: with no nesting and no node numbering, a complex process spreads across connectors and becomes unworkable; once it no longer fits on a page, it is too large for a flowchart, and it must be broken up, for example with functional decomposition, or a notation built for scale must be adopted. Rules baked into the flow: BABOK signals its sharpest limitation, a model becomes intractable when business rules are not managed separately from the process; better to extract those rules, into business rules analysis, than to draw every branch. Obsolescence, finally: a flowchart kept as a mere piece of documentation drifts from reality as the process changes without the drawing following.

Placing the flowchart among the neighbouring notations avoids asking it for what it cannot carry. The circulation and transformation of data within a system belong to the data flow diagram, which models the movement of data and not the sequencing of control. The four process-modelling notations stand against one another on the properties that genuinely separate them.

AI considerations

Two uses hold. The first draft from a text: a language model turns a written procedure or an interview write-up into a flowchart structure, steps and branches, which analysis then corrects, quick scaffolding for a current state. Notation clean-up: converting a drawing in house conventions to a consistent ISO 5807 set or rearranging a tangled flow. Consistency checking: spotting a diamond missing a branch, a step no path reaches, a terminator with no way out.

Judgement, for its part, does not delegate. The real process is not the documented process: a model writes from what it is given, but only the stakeholders know what really happens, exceptions included, and the value of a flowchart is the validated agreement. Deciding what is a decision, which branches are binary tests and which are business rules to extract from the flow, is analysis work; getting it wrong means letting the tool faithfully draw the intractable model BABOK dreads. Scope and level remain a human choice, a model readily over-detailing a flat drawing until it becomes unworkable. The approval thresholds and the roles of a company, finally, are sensitive data that are not entrusted to a tool that does not respect them.

Examples

The approval procedure for an expense claim in a Swiss SME. The employee submits the claim together with the receipt; the line manager checks it; a test decides, "amount over CHF 1'000?"; above the threshold, it goes to the finance department for approval; below it, it is paid with the next payroll run. The concept the drawing makes visible is that the diamond is the test, decided on the spot, and that the shape of each box is enough to state its nature.

Three specialised shapes make this drawing a flowchart: a parallelogram for the submitted claim, an input; a document symbol, with a wavy bottom edge, for the receipt; a double-barred rectangle for the settlement with payroll, a sub-process handled in detail elsewhere. Nothing crosses an organisational boundary, everything plays out within a single company, and BPMN would add nothing to this example.

Visualizations

The geometry is the content. The shape of a box carries its nature, so that a rectangle put in the place of a parallelogram would state something else, and a diamond with three exits, another notation. The four families of shapes are therefore clearly told apart by the eye, and the arrows carry a solid head that gives the direction of reading. The drawing reflows on a phone rather than overflowing, and its labels are text, selectable and readable by a screen reader.

Cost

Tooling

The whiteboard is enough, and this economy is a property of the technique: a handful of shapes fits on a flip chart and is drawn in front of the people who do the work, which is the very reason a non-technical audience reads a flowchart without training. General-purpose drawing tools, Visio, diagrams.net or Lucidchart, carry flowchart stencils and align shapes, connectors and lanes; their contribution stops at the drawing.

As soon as a model outlives a workshop, one capability is worth demanding of the tool, since several consistency checks are mechanically verifiable: flagging a diamond with a missing branch, a step no path reaches, a terminator with no way out. Beyond that, if the process calls for messages between organisations, execution in an engine or true concurrency, another notation is what is at issue.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.35 Process Modelling: the definition, the list of the elements of a process model (activity, event, directional flow, decision point, link, role) and the technique's acknowledged limitations.
• ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.3 Flow Charting: the ANSI lineage, the flat model and its connectors and the notation's use with a non-technical audience.
• ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.2 Swim Lanes: swimlanes are a notational addition and not a distinct notation.
• ISO, ISO 5807:1985, Information processing, Documentation symbols and conventions for data, program and system flowcharts: the symbol set itself, the one that makes the parallelogram an input and the wavy-edged box a document; its ancestor is the ANSI X3.5 standard.
• PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th ed., ch.5 Tools and Techniques, "Flowchart": the framing of the flowchart as a process map.