In many companies the flowchart shows up at two typical moments. First, when a consultant draws it during a certification and leaves it in a PDF nobody opens again. Then, when a new team member asks "how does this thing work?" and nobody can answer without calling the person who has always done it.
Between these two extremes there's practical ground. A business process flowchart is a graphic representation of the activities, decisions and information flows of a process, built with standard symbols. The ISO 5807 standard defines the basic symbols; the BPMN 2.0 notation — also adopted as ISO/IEC 19510 — is the modern reference for more complex processes [1][2].
ISTAT data (2025) show that fewer than half of small and medium-sized companies in Italy use integrated management software: 48.8% versus 85.9% of large companies [3]. The Bank of Italy finds that the systematic collection and use of information to monitor and improve the production process is among the structured management practices positively associated with company productivity [4].
This article describes how to build a useful flowchart: when you really need one, which notation to choose, the step-by-step process for drawing it, the tools that fit the size of your organization and the mistakes that turn it into wallpaper.
When a business process flowchart is really useful (and when it's just decoration)
How many flowcharts, in small and mid-sized companies, are consulted more than once after being drawn? In most cases, none. Wallpaper only certifies that someone, once, gave it a try.
The first mistake isn't drawing a flowchart badly, it's drawing one when it isn't needed. What the Bank of Italy associates with productivity isn't documentation in itself, but the systematic use of the information collected to monitor and improve the production process [4]; value doesn't come from the graphic representation, but from the fact that the people who run the process can read it, understand it and follow it. This section sets out the working definition, separates the flowchart from the terms it's most often confused with and identifies the three cases where building one returns a measurable benefit.
Working definition. A business process flowchart is a graphic representation of the activities (actions), decisions (forks), information flows (arrows) and material flows of a process, built with standard symbols agreed in advance between the people who draw it and the people who use it.
Telling apart closely related terms.
Flowchart vs process map. The flowchart is a graphic tool (the sheet, with its symbols). The process map is the result of the mapping activity, which can use different graphic tools — including the flowchart. Mixing up the two terms leads people to write "build the process map" when they mean "draw a flowchart", and vice versa.
Flowchart vs BPMN. The "classic" flowchart (ISO 5807) uses a few basic symbols and anyone can read it [2]. BPMN is a richer standard notation (more than a hundred symbols) designed for complex processes with events, conditional gateways and subprocesses [1]. A common confusion: thinking that "making a flowchart" necessarily means using BPMN. For most organizations, it doesn't.
Flowchart vs flow diagram. They're synonyms — "flowchart" is the more common term in software and manuals, "flow diagram" in more general usage. The confusion is purely lexical.
Flowchart vs swim lane diagram. The swim lane diagram is a variant of the flowchart that adds functional lanes (who does what). It's an extension of the flowchart, not a separate tool.
The three cases where the diagram is really useful.
Onboarding and handovers. When a new team member has to learn a process, a readable flowchart cuts the time spent shadowing. When someone leaves the role, an up-to-date flowchart transfers knowledge that would otherwise have stayed in their head.
Cross-functional processes with blurred responsibilities. When a process runs across several functions (sales, operations, administration) and it isn't clear who does what at each step, the swim lane flowchart resolves the ambiguity visually.
A prerequisite for review or automation. Before improving a process, or before automating it, you need a clear representation of how it works today. An undocumented process can't be improved systematically.
For the broader picture of business process mapping — which includes choosing which processes to represent and in what priority — the dedicated cluster is the reference. For the link between the flowchart and the business procedures that derive from it, the reference pillar is available.
Choosing the right notation: classic flowchart, BPMN or swim lane
Is it really worth learning BPMN to draw the complaint-handling process of an eight-person repair shop? The most common answer is no. The most common answer inside companies, however, is "yes, because that's what the market does."
The ISO 5807 standard [2] codifies a small set of symbols — rectangle for activities, diamond for decisions, oval for start and end, parallelogram for input and output, arrow for flow — which is enough for most processes in a small or mid-sized company. The BPMN 2.0 notation [1], standard ISO/IEC 19510, is more powerful but has more than a hundred symbols and is justified only when the process requires it. The swim lane is a variant of the flowchart that adds functional lanes to clarify who does what.
A selection matrix with three variables.
| Notation | Process complexity | Number of functions involved | Who the map is for |
|---|---|---|---|
| Classic ISO flowchart | Simple to medium (up to 10-15 steps) | A single function | Anyone in the company |
| Swim lane | Medium (10-20 steps with several responsibilities) | Two or more functions | The people who run the process |
| BPMN | High (processes with exceptions, subprocesses, conditional events) | Multiple, with systems integration | Process designers, IT |
Rule of thumb. Start with the classic ISO flowchart. Add the swim lane when responsibilities across functions are the main source of ambiguity. Introduce BPMN only when the process requires modeling events, multiple conditional gateways or integration with IT systems — and when someone exists who can read BPMN.
The step-by-step process for building a readable flowchart
Who should draw the diagram: the manager who knows the "official" process, or the person who actually runs it every day? In the projects we've observed, the first choice is the most common. The second is the one that produces useful maps.
A well-made flowchart is built in five sequential steps: identify the start and end of the process, list the intermediate activities, recognize the decision points, assign responsibilities (if you're using swim lanes), validate the first draft with the people who run the process. The methodological reference is the textbook by Dumas et al. (2018) [5], which devotes a chapter to "essential modeling" and symbolic parsimony — keeping only the symbols the map's audience needs. This section describes each step with indicative times and a practical rule: each step should produce an artifact you can check before moving on to the next.
Step 1 — Identify the start and end of the process. Indicative time: 15-20 minutes. Artifact: two sentences — "The process starts when [event/trigger]" and "The process ends when [output/delivery]". Getting these two boundaries precise is the condition for not getting lost in the complexity of the next step.
Example: for the customer complaint-handling process, the start is "the customer sends a complaint by email or phone" and the end is "the complaint is closed and the customer receives a message with the outcome". Everything that happens in between is the body of the process.
Step 2 — List the intermediate activities. Indicative time: 30-45 minutes with the people who run the process. Artifact: a numbered list of real activities — how they're done today, not how they should be done. The list is built with the person who runs the process, not without them.
Rule of thumb: if an activity includes a verb that is neither "check", nor "decide", nor a direct action (fill in, send, update, approve, receive), it's probably too generic or hides two separate activities.
Step 3 — Recognize the decision points. Indicative time: an additional 15-20 minutes. Artifact: for every point in the flow where the process takes different paths, a yes/no question. The diamonds in the flowchart represent these forks: "does the order value exceed 5,000 euros?" → yes (path A) / no (path B).
The most common mistake is describing decisions as activities: "approve the order" is an activity; "is the order approved?" is a decision point. The difference is visual in the diagram, but even more important in the written text that accompanies it.
Step 4 — Assign responsibilities (swim lane). Indicative time: an additional 10-15 minutes. Artifact: every activity and every decision assigned to an explicit function or role. If you're using swim lanes, each lane corresponds to a role.
Parsimony rule: responsibilities are assigned by role (sales manager, operations manager, administration manager), not by person. The person changes; the role doesn't.
Step 5 — Validate with the people who run the process. Indicative time: 30 minutes with the team that runs the process. Artifact: the draft annotated with corrections. This is the step most often skipped, and the one that makes the biggest difference. If the people who run the process ask more than two clarifying questions about the draft, the diagram isn't ready yet.
Readability rule: if a symbol needs a legend to be interpreted, it's a candidate for removal. A diagram that works without a legend is a diagram that will be used; one that needs a legend tends to end up in the archive.
For the link between the flowchart and the standard operating procedures (SOPs) that formalize each step in written language, the dedicated cluster is the reference. The flowchart shows the flow; the SOP describes how to carry out each individual step.
Selecting the right tool: from paper to professional software
Will a professional flowchart platform really solve the problem, or will it turn it into a new software adoption problem? In smaller companies the second scenario is common — and it matches the gap in digital tool adoption that ISTAT measured in Italy.
The ISTAT survey (2025) finds that the digital equipment of Italian small and medium-sized companies remains far behind that of large companies on every management tool surveyed, from ERP software (48.8% versus 85.9%) to data analysis tools (41.9% versus 83.6%) [3]. This isn't an obstacle: for your first flowchart, sticky notes on a wall and a camera often produce a more useful result than any software. This section proposes a three-level scale, with guidance on when to move from one level to the next. The criterion isn't company size, it's the maturity of your existing documentation and how often the map gets updated.
Level 1 — Manual (paper, sticky notes, whiteboard). When to use it: in the initial phase of building the flowchart, especially with the team that runs the process. It lets you move steps around, add or remove activities without the friction of software. Sticky notes on a whiteboard are the most versatile tool for the exploration phase. Limit: it isn't easy to share digitally and it isn't easy to update.
Level 2 — General-purpose digital diagramming tool. When to use it: when the flowchart needs to be shared digitally, stored in the company's document system or used as a reference by a distributed team. This category includes cloud diagramming tools that don't require specific training. Limit: it doesn't automatically pull information from your management software or workflow system: it remains a manual tool, even if digital.
Level 3 — Professional Business Process Management platform. When to use it: when the process represented is directly connected to automated workflows, when the diagram has to stay in sync with the IT system, or when you need formal process governance. For small and mid-sized companies, this level is rarely justified before level 2 is well established. For the link with business process automation, the dedicated cluster covers the conditions under which the professional level becomes necessary.
Criterion for moving up: you move from level 1 to level 2 when you have more than 5 flowcharts and they're used regularly. You move from level 2 to level 3 when the flowcharts need to integrate with IT systems or workflow automation. Level 3 without a technical owner to manage it becomes an unused investment.
Recognizing the common mistakes that make a flowchart useless
Does the diagram you just drew represent the process as it really is, or as you'd have liked it to be? In most first attempts, the second hypothesis is closer to reality.
A badly drawn flowchart is worse than no flowchart at all. It locks in inefficiency, gives the illusion of control and breeds organizational cynicism toward every later attempt at formalization. The Business Process Management literature (Dumas et al., 2018 [5]) collects a catalog of recurring mistakes. This section groups them into the six most common, in the format "mistake → warning sign → practical fix".
Mistake 1 — Overusing BPMN symbols on simple processes. Warning sign: the diagram needs a legend to be read; people looking at it ask "what does that symbol mean?". Fix: use the classic ISO flowchart (5 basic symbols) for any process that doesn't require representing conditional events or subprocesses. Introduce BPMN only when the complexity of the process justifies it.
Mistake 2 — No validation with the people who run the process. Warning sign: the diagram was built only by the manager or by senior management; the people who run the process find it inaccurate or don't recognize it as their own process. Fix: involve the people who run the process in Step 5 (validation). The question to ask: "Does this describe how you do the process today, not how it would be best to do it?"
Mistake 3 — An "ideal" map instead of the real one. Warning sign: the diagram doesn't include the exceptions, workarounds or variants that exist in day-to-day practice. Fix: build the "as-is" map first (how it works today), then the "to-be" map (how it should work). The two maps answer different questions and shouldn't be confused.
Mistake 4 — Decisions represented as activities. Warning sign: there's no diamond (decision) in the diagram; all the steps are rectangles (activities). The process looks linear even when it isn't. Fix: identify every point in the process where a choice is made between two different paths and represent it with a diamond. At least one decision in every process of medium complexity.
Mistake 5 — Orphan map (no owner, no review date). Warning sign: the file has no visible last-modified date; it isn't clear who's responsible for updating it. Fix: add to the document the creation date, the date of the last review and the name of the person responsible for updates. Without these elements, the diagram becomes wallpaper within six months.
Mistake 6 — Mixing levels of abstraction. Warning sign: the same diagram contains both the high-level process view (e.g. "customer order management") and the operational detail of a single step (e.g. "open the management software, click on 'new order', enter the customer code"). Fix: separate the levels. The process diagram shows the high-level phases; the work instruction or written procedure describes the technical detail. The two documents complement each other; one doesn't replace the other.
Limits and conditions of applicability
Non-repeatable processes. A flowchart is useful for recurring processes. For creative work, customized consulting or work with a high tacit-knowledge content (where every case is different), a rigid flowchart can get in the way more than it helps. In these contexts, a quality checklist or a flexible template is often a better fit.
Continuous updating. A flowchart that isn't updated when the process changes quickly becomes obsolete and counterproductive. The rule of thumb is the same as for written procedures: trigger event + periodic review + owner.
Sources [1] and [2]. The ISO/BPMN specifications are technical standards, not sources of empirical data. The statements about their use in small and mid-sized companies derive from ISTAT [3] and Bank of Italy [4] data, which document the Italian adoption context without specific reference to individual notations. Neither source directly measures how widespread graphic process representation tools are: ISTAT surveys the adoption of management and analytics software, the Bank of Italy the presence of structured management practices on monitoring, targets and incentives.
FAQ — Frequently asked questions about business process flowcharts
How long does it take to build a flowchart? For a process of medium complexity (10-15 steps, one or two functions involved), the full cycle of the 5 steps takes 2-4 hours spread across several sessions. The longest phase is often validation with the people who run the process.
Can a flowchart replace a written procedure? No, but it complements it. The diagram shows the visual flow (what happens, in what order, who does it). The written procedure describes how to carry out each individual step (with what criteria, in how much time, with what output). For the most critical processes, both documents are useful.
Do you need specific software to make flowcharts? No. Sticky notes on a whiteboard, then photographed, are an excellent starting point. Software adds value when the flowchart needs to be shared digitally, kept for a long time or updated frequently.
Operational summary
A useful business process flowchart is built in five steps (identify the start and end, list the activities, recognize the decision points, assign responsibilities, validate with the people who run the process), drawn with the notation that fits its audience (ISO flowchart for most cases, swim lane when cross-functional responsibilities are the source of ambiguity, BPMN only for complex processes with systems integration), and supported by the minimum level of tooling needed (paper in the exploration phase, digital when you need to share it, professional only when automation requires it).
The six most common mistakes (BPMN on simple processes, no validation, ideal map instead of real, decisions as activities, orphan map, mixed levels) are avoided with a single practice: have someone who didn't draw the diagram read it before you consider it complete.
Conclusion
A flowchart isn't a certification document, it's a working tool. Drawn badly, it ends up in a drawer within three months. Drawn with the right level of detail and validated with the people who run the process, it becomes the basis for onboarding a new team member in days instead of weeks, for spotting the decisions that slow a flow down and for preparing the process for automation.
The working idea is simple: choose the notation that fits the map's audience, build the diagram in five sequential steps validating it at each stage, use the lightest possible tools in the first phase. When a flowchart can be read by the people who have to run it — not just by the person who drew it — it has already done half the work.
To place the flowchart within the broader activity of process mapping, which includes choosing which processes to represent and by what criteria, the dedicated in-depth article is available. To turn the flowchart into instructions your team members can carry out, the next step is formalizing your business procedures.
A company whose processes are represented in a readable way is a company where people don't ask "how do you do this?" every time someone new joins. Decisions are made where they should be made, exceptions are recognized as such, and the business owner stops being the only one who knows how the machine works. A flowchart, on its own, doesn't produce this result. But it's the first layer of an organization that lets itself be observed — and improved.
Sources and references
[1] Object Management Group, "Business Process Model and Notation (BPMN) 2.0", OMG, 2011 (adopted as ISO/IEC 19510:2013). Available at: https://www.omg.org/spec/BPMN/2.0/
[2] International Organization for Standardization, "ISO 5807:1985 — Information processing — Documentation symbols and conventions for data, program and system flowcharts", ISO, 1985. Available at: https://www.iso.org/standard/11955.html
[3] ISTAT, "Imprese e ICT, Anno 2025", Istituto Nazionale di Statistica, 2025. Available at: https://www.istat.it/comunicato-stampa/imprese-e-ict-anno-2025/
[4] Baltrunaite, A., Formai, S., Linarello, A., Mocetti, S., "Proprietà, governance, management e performance delle imprese: evidenze dalle imprese italiane", Banca d'Italia, Questioni di Economia e Finanza no. 678, March 2022. Available at: https://www.bancaditalia.it/pubblicazioni/qef/2022-0678/QEF_678_22.pdf
[5] Dumas, M., La Rosa, M., Mendling, J. and Reijers, H. A., "Fundamentals of Business Process Management", Springer, 2nd ed. 2018. Available at: https://link.springer.com/book/10.1007/978-3-662-56509-4