The operations director of a distribution company orders a complaint-handling system. The description of needs fits on two pages: the customer files a complaint, an employee reviews it, the warehouse collects the goods, the customer gets an answer. Three vendors send proposals: PLN 180,000, 420,000 and 950,000. None of them made a mistake. Each priced a different system, because each imagined differently what happens between “files” and “gets an answer”.
That spread is not unusual. In PMI’s Pulse of the Profession study on requirements management, 47% of unsuccessful projects failed to meet their goals because of inaccurate requirements management, and 5.1% of every dollar spent on projects was wasted for the same reason. The cheapest moment to remove that ambiguity is before the request for proposal, not in the third sprint.
BPMN 2.0 removes it. It is not a notation reserved for analysts or workflow engines but a shared language in which operations, the program manager and the vendor see the same process. Below: which elements you really need, how detailed a diagram should be, a complaint process modelled step by step, and how to turn it into requirements that can be priced.
What is BPMN 2.0 and where did the standard come from?
BPMN (Business Process Model and Notation) is a standard graphical notation for describing business processes. The first version was developed in 2004 by the Business Process Management Initiative. After it merged with the Object Management Group (OMG) — the same body that maintains UML — the standard passed to OMG.
Version 2.0 was published in January 2011 and was a breakthrough for two reasons. First, it changed the name from “Business Process Modeling Notation” to “Business Process Model and Notation” — alongside the graphical symbols came a formal metamodel and an XML interchange format. Second, it defined execution semantics: a diagram drawn according to the standard can be run in a process engine without translation into another language.
In 2013 the content of BPMN 2.0.1 was adopted as the international standard ISO/IEC 19510:2013. In December 2013 OMG published release 2.0.2 with minor corrections, and it remains current. That stability is an asset: a 2015 diagram opens in a 2026 tool.
BPMN has several diagram types — process, collaboration, choreography and conversation. Before ordering software you need the first two. A process diagram describes the steps inside one organisation. A collaboration diagram shows how several parties — your company, the customer, a courier, a bank — exchange messages.
It is also worth knowing what BPMN is not. It does not describe data structures (that is what a data model or a UML class diagram is for), screen layouts (mockups) or complex decision logic (that is what DMN is for, covered below). It describes the order of work, responsibility and decision points — exactly what most often goes unsaid in a request for proposal.
Why describe a process in BPMN before you order software?
Prose lets you skip exceptions without noticing. The sentence “an employee reviews the complaint” sounds complete. A BPMN diagram with the same step immediately raises questions: what happens when the submission is incomplete? Who decides when the amount exceeds a limit? What if the customer does not reply within a week? Each answer is a system function — and each changes the price.
Our experience in software development projects points to four concrete benefits of describing the process before the request for proposal:
- Comparable proposals. Vendors price the same scope. The spread of proposals stops reflecting different ideas of the system and starts reflecting differences in rates, approach and risk — which is what you actually want to compare.
- Exceptions visible before pricing. The main path of a process usually takes a smaller share of developer work than handling exceptions: rejections, missing data, missed deadlines, integration errors. A diagram forces you to name them.
- A clear split between human and system work. BPMN distinguishes tasks done by a person in the system, tasks done automatically and manual tasks outside the system. That split is, in practice, the boundary of the project’s scope.
- A reference point for changes. When a new requirement appears mid-project, the diagram shows whether it fits the agreed process or is a new element of scope. A dispute over interpretation becomes a conversation about a specific part of the model.
The last point matters especially in fixed-price contracts. As we wrote in our article on who really pays for risk transfer in fixed-price software, a vendor prices ambiguity as risk and adds it to the price. A process diagram reduces that ambiguity — and with it, the risk premium.
What elements make up a BPMN diagram?
The BPMN 2.0 specification describes well over a hundred elements and attributes, which discourages many people at the outset. In practice, a dozen or so are enough to describe a business process before ordering software. They fall into five groups.
Flow objects — what happens in the process:
- Events (circles) — something that happens: the start of the process, the arrival of a message, the passage of time, an error, the end. A thin circle is a start event, a double one an intermediate event, a thick one an end event.
- Activities (rounded rectangles) — work to be done. A task is an atomic activity; a sub-process is an activity with its own detailed diagram.
- Gateways (diamonds) — points where the flow splits or merges.
Connecting objects — how elements are linked:
- Sequence flow (solid line with an arrow) — the order of steps within one pool.
- Message flow (dashed line with a small circle at the start) — the exchange of information between pools, for example between the company and the customer.
- Association (dotted line) — links annotations and data to process elements.
Swimlanes — who does the work:
- Pool — a process participant, usually an organisation (your company, the customer, a courier service).
- Lane — a role or department within a pool (customer service, warehouse, quality).
Data — data objects (documents, forms, records passed between steps) and data stores (systems where data is kept permanently, such as an ERP).
Artifacts — text annotations and groups, which change nothing in the process logic but help people understand it.
For someone ordering software, the most important attribute is the task type, shown by an icon in the corner of the rectangle. A user task (person icon) means a human does the work in the system — a screen is needed. A service task (gears icon) means an automatic system operation — usually an integration. A manual task (hand icon) is work outside the system, such as physically inspecting goods. A business rule task (table icon) is a decision made according to defined rules. In practice, these four icons define what the vendor has to build and what it does not.
How do you read gateways and events so the diagram does not mislead?
Gateways and events are where BPMN diagrams most often say something different from what the author meant. Yet they carry the most information for developers.
An exclusive gateway (XOR), an empty diamond or one marked “X”, selects exactly one path. Every outgoing path should have a named condition: “amount up to PLN 500”, “amount over PLN 500”. Conditions must be mutually exclusive and cover every case — if you write “over PLN 1,000” instead of “over PLN 500”, the diagram does not say what happens to a PLN 700 complaint, and a developer will guess.
A parallel gateway (AND), a diamond with ”+”, activates all paths at once. A merging gateway of the same type waits for all of them to finish. It tells the reader that two departments can work independently — which usually shortens the process but requires the system to handle parallel tasks.
An inclusive gateway (OR), a diamond with a circle, activates one or more paths whose conditions are true. It is the hardest to understand and test, which is why modelling guidelines recommend avoiding it. It can usually be replaced by a combination of XOR and AND gateways.
An event-based gateway, a diamond with a pentagon in a circle, waits for whichever of several events happens first. It is the ideal way to describe “we wait for the customer’s reply, but no longer than 7 days”.
Events have types, shown by an icon inside the circle. Four matter most before ordering software:
- Message (envelope) — a message arriving or being sent: an email, a web form submission, a response from another system. Each such event is an integration point or a communication channel.
- Timer (clock) — a deadline passing or a specific date. Each timer event is a requirement that the system must track time and act when a deadline expires.
- Error (lightning bolt) — a situation that interrupts the normal flow. An error event attached to the edge of a task (a boundary event) says: “if this task fails, take this path”.
- Escalation (upward arrow) — passing a case upward without interrupting current work.
Boundary events are especially valuable: a clock on the edge of the “Assess defect” task with the annotation “5 working days” is one of the most precise requirements you can hand a vendor: the system must count working days and trigger an escalation when they run out. Prose would take a paragraph and still leave working versus calendar days open.
Which level of detail should you choose: descriptive, analytic or executable?
The most common modelling mistake is not a wrong symbol but the wrong level of detail: too general does not help pricing, too detailed will not be read.
The BPMN 2.0 specification defines three process modelling conformance subclasses, which in practice correspond to three levels of detail:
| Level | For whom | What it contains | When it is enough |
|---|---|---|---|
| Descriptive | Executives, process owners | Tasks, basic gateways, start and end events, lanes | Agreeing on what the process looks like at a high level; a company process map |
| Analytic | Program manager, analyst, software vendor | Task types, all gateway types, timer, message and error events, boundary events, data objects, pools and message flows | Request for proposal, pricing, agreeing project scope |
| Common Executable | Developers, workflow engine | All of the above plus data types, condition expressions, service and integration definitions | Running the process in a BPMN engine |
Before ordering software, aim for the analytic level. It shows exceptions, deadlines, integrations and the split of work between people and the system — everything that changes the price. The descriptive level is too imprecise because it omits exactly those elements. The executable level is a technical design that should be created with the vendor, as it depends on the chosen technology.
Decomposition is good practice too: the main process on one diagram, complex fragments as sub-processes on separate diagrams. The research by Mendling, Reijers and van der Aalst behind the Seven Process Modeling Guidelines (7PMG) found that in models with more than 50 elements the probability of an error exceeds 50%. A diagram that does not fit on one screen will not be read by the people who have to approve it.
How do you model a process step by step, using complaint handling as an example?
Back to the distribution company from the introduction. Here is how, in seven steps, a two-page description becomes a diagram that three vendors will price the same way.
Step 1. Set the process boundaries. Define the start and end events. Start: “Complaint received” (a message event — a submission from a web form, an email or a courier). End: three end events — “Complaint accepted and settled”, “Complaint rejected”, “Complaint closed without review”. This step alone reveals that the process has three outcomes, not one.
Step 2. Name the participants. A “Customer” pool (collapsed — we do not model its internal steps, only the messages) and the company pool with lanes: Customer service, Warehouse, Quality. If goods are collected by an external courier through an API, add a third pool, “Courier” — an immediate integration signal.
Step 3. Model the main path. First the case in which everything goes well: Register complaint → Check warranty eligibility → Order goods collection → Assess defect → Issue decision → Settle complaint. Naming tasks as “verb + noun” is one of the 7PMG guidelines — “Assess defect” rather than “Assessment” or “Quality department”.
Step 4. Add decisions. After registration: an XOR gateway, “Is the submission complete?”. If not, a task that sends a request for the missing information and an event-based gateway: either a message with the completed information arrives, or after 7 days a timer event ends the process as “closed without review”. After the eligibility check, another XOR gateway: under warranty / out of warranty.
Step 5. Set the task types. “Register complaint” — a user task (a screen for customer service). “Check warranty eligibility” — a business rule task (a decision table: purchase date, product category, sales channel). “Order goods collection” — a service task (integration with the courier’s API). “Assess defect” — a manual task plus a user task to record the result.
Step 6. Add parallelism and deadlines. Once eligibility is confirmed, an AND gateway starts goods collection and opens a quality ticket at the same time. On the “Assess defect” task, a boundary timer event: after 5 working days, escalation to the department manager. The most important deadline comes from law: since 1 January 2023, Article 7a of the Polish Consumer Rights Act requires a business to respond to a consumer complaint within 14 days, and a missing response means the complaint is deemed accepted. That is a timer event at the level of the whole process — and a requirement whose breach costs the company real money.
Step 7. Walk through the diagram with the people who do the work. Not with their managers. A customer service employee will tell you in five minutes that a fifth of complaints arrive by phone and someone has to retype them; a warehouse worker, that some goods are returned in person at a branch, without a courier. Those are two more paths that appeared in no document.
The finished diagram has about 30 elements, fits on one screen, and answers the questions that three vendors had previously settled in three different ways: which submission channels exist, where the integrations are, which decisions are made by people and which by rules, and which deadlines the system must track.
How do you turn a BPMN diagram into requirements for a software vendor?
A diagram does not replace a specification, but it is its best skeleton. Every element of an analytic BPMN model maps to a specific type of requirement:
| BPMN element | What it means for the vendor | Example from the complaint process |
|---|---|---|
| User task | A screen or form, role permissions from the lane | Complaint registration form for customer service |
| Service task | Integration with another system or API | Collection order via the courier’s API |
| Business rule task | A configurable decision table | Warranty eligibility by purchase date and category |
| Manual task | Work outside the system — do not build it, only record the result | Physical assessment of the defect by quality |
| Message event | An input or output channel, a notification | Web form, email, SMS notification to the customer |
| Timer event | A schedule, an SLA, a reminder | The 14-day deadline under Article 7a, escalation after 5 days |
| Error event | Exception handling, a message, an alternative path | No response from the courier API |
| XOR gateway with a condition | A validation or branching rule | Submission complete / incomplete |
| Data object | A field, document or attachment | Photos of the defect, proof of purchase |
| Lane | A role and permissions in the system | Customer service, Warehouse, Quality |
A table like this produces a list of functional requirements, while timer and error events provide non-functional ones: response times, integration availability, deadline auditing.
In agile projects, a BPMN diagram works well with a backlog. Each user task becomes one or more user stories, each service task an integration story, each exception path an acceptance criterion. The diagram answers “in what order and in what context”; the stories answer “what exactly should happen on this screen”. Use cases work similarly: they describe a user’s interaction with the system within a single process step.
Decisions are worth modelling separately. DMN (Decision Model and Notation), also maintained by OMG, describes decision rules as tables. A business rule task in the BPMN diagram marks where the decision happens; a DMN table holds its logic. As a result, changing an amount limit or a warranty period requires no redrawing of the process, and often no code change.
Which BPMN diagram mistakes most often spoil project pricing?
Mendling, Reijers and van der Aalst formulated seven guidelines that reduce errors in process models: use as few elements as possible, minimise the routing paths per element, use one start and one end event, model as structured as possible, avoid OR gateways, use verb–object activity labels, and decompose a model with more than 50 elements. The third guideline is often relaxed in practice — several named end events, as in our example, are frequently easier to read than one.
In the requests for proposal we analyse, six mistakes recur that translate directly into proposals that cannot be compared:
- Only the happy path. A diagram without a single error event and without rejection paths. The vendor either adds exception handling by guesswork or leaves it out — and returns with it as a change request.
- Gateways without conditions. A diamond with two arrows and no labels. The developer does not know who chooses the path or on what basis.
- No task types. Every task drawn as a plain rectangle. Nobody knows which need a screen, which an integration and which happen outside the system. This is the single biggest source of price spread.
- The process “as it should be”, not “as it is”. A target process model without a current-state model hides the channels and workarounds people use today — phone calls, spreadsheets, emails to a manager. They surface after go-live.
- Mixed levels. “Approve sales strategy” and “Click the Save button” on the same diagram. It stops being readable for anyone.
- Department names instead of activities. A task called “Accounting” does not say what accounting does. “Issue invoice correction” does.
Each can be spotted in an hour’s review — ideally by an analyst from outside the team who understands the difference between business and systems analysis.
When is BPMN not the right tool, and what should you use instead?
BPMN describes processes with a predictable order of steps very well. There are situations, though, in which it imposes artificial structure or does not answer the right questions.
Knowledge work without a fixed sequence. Handling a legal case, a medical diagnosis, analysing a security incident — the order of steps depends on what the specialist discovers. Drawing it in BPMN ends in a diagram where everything connects to everything. OMG has a separate standard for this, CMMN (Case Management Model and Notation), but in practice a list of possible actions with rules for when they are available is often enough.
A digital product for end customers. A mobile app or an online shop is mostly free user navigation, not a process. Customer journey maps, user story mapping and mockups work better. BPMN becomes useful only in back-office processes — order fulfilment, returns, payments.
Interaction between system components. The order of calls between services, queues and databases is described with a UML sequence diagram or architecture diagrams, not BPMN. That is a technical level that belongs to solution design, not to the request for proposal.
Complex decision rules. Ten XOR gateways arranged as a tree signal that a decision is hiding in the process. Pull it out into a DMN table and leave one business rule task in the process.
A very early idea stage. If you do not yet know which problem you are solving, drawing the process is premature. First comes product discovery — goals, users, hypotheses — and only then a process model.
Which BPMN modelling tools should you choose in 2026?
The choice of tool matters less than conformance with the standard. The key criterion: does the tool save the diagram as BPMN 2.0 XML that can be opened elsewhere? A diagram saved only as an image or in a closed format is documentation the vendor cannot reuse.
Tools fall into four groups:
- Lightweight standard-compliant editors — bpmn.io and the Camunda Modeler built on it (free, save clean BPMN 2.0 XML), as well as draw.io with a BPMN shape library (convenient, but without model validation). Good for getting started and for requests for proposal.
- Business analyst tools — Bizagi Modeler, Visual Paradigm, Enterprise Architect. They validate models, generate documentation and support simulation.
- Enterprise process management platforms — SAP Signavio, ARIS. A repository of all company processes, versioning, collaboration and analysis based on system data (process mining). They make sense when a company manages dozens of processes, not a single project.
- Workflow engines with a modeler — Camunda 8, Flowable and others. Here the diagram is also code running in production.
One change from the past year matters for companies already running processes in an engine: Camunda 7 Community Edition reached end of life in October 2025 — the final release, 7.24, came out on 14 October 2025, and the repository was archived. The Enterprise edition is supported until at least 2030. Camunda 8 is not a simple upgrade but a new architecture, so migration is a project in its own right. If your processes run on unsupported Camunda 7 CE, plan the migration deliberately rather than under the pressure of the first security vulnerability.
AI-generated BPMN diagrams work increasingly well for simple processes, but models readily draw the happy path and skip exceptions — the most valuable part. Treat them as drafts to review with the people who do the work.
How does BPMN support process automation and workflow engines?
An analytic BPMN diagram prepared before ordering software has one more benefit: it can become the foundation of process automation, not just documentation.
In a traditionally built system, the process is buried in code — conditions, statuses and schedules scattered across the application — so every change needs developers.
With a workflow engine, the same BPMN diagram, completed to the executable level, is run directly. The engine enforces the order of steps, deadlines and escalations, assigns tasks to users in the right lanes and calls integrations in service tasks. Monitoring is built in: you can see how many cases are at each step, where queues form and which deadlines are at risk.
It is not always worth it. An engine makes sense for long-running processes (days or weeks) with many participants, deadlines and frequent changes. For a simple process within one screen, well-written code is enough. Decide with the vendor, based on your analytic diagram.
A BPMN engine also differs from RPA (robotic process automation), which automates individual tasks by imitating human clicks and typing; the engine orchestrates the whole process. The two complement each other: a manual task such as “Retype complaint from email into the ERP” is a good candidate for an RPA bot, and the whole complaint process for orchestration.
Who in the company should prepare the diagram, and how long does it take?
The usual answer to “who will draw the process” is “the vendor, as part of the analysis”. That is reasonable when choosing a single partner, but not when comparing proposals. If each of three vendors must first analyse the process, you get three analyses and three prices that still cannot be compared. A diagram meant for comparing proposals has to be created on the buyer’s side.
A split of roles that works: the program manager owns the result, the process owner — usually the head of the department that gains or loses on the process — approves the model, and a business analyst runs the workshops and draws the diagram. The analyst does not need to be a domain expert. Their job is to ask about the exceptions that people doing the work every day no longer notice. If the company has no such person, business analysis can be brought in for the duration of the request — usually a few weeks of work, not a permanent role.
How long does it take? For a process of medium complexity, like the complaint handling in our example, our experience is that two or three workshops of two to three hours each are enough: the first for process boundaries, participants and the main path; the second for exceptions, decisions and deadlines; the third to walk through the finished diagram with the people who do the work. Between workshops, the analyst tidies the model and gathers questions. In total, from a few days to two calendar weeks.
Cross-functional processes such as order-to-cash take longer. Start with a descriptive map, pick the fragments the project concerns and model only those analytically — drawing the whole company in detail produces documentation that is out of date before it is finished.
One rule prevents most problems: the diagram is ready when the person doing the work recognises their day in it, not when the board approves it.
How do you prepare a process package before a request for proposal?
The BPMN diagram is the most important, but not the only, part of a package that lets vendors price a project reliably. The checklist below summarises what to prepare and how mature your documentation is:
| Area | Level 1: insufficient | Level 2: basic | Level 3: ready for pricing |
|---|---|---|---|
| Process model | Text description | Descriptive diagram, main path only | Analytic diagram with exceptions, up to about 50 elements per diagram |
| Current state | None | Verbal description of current problems | ”As-is” diagram with workarounds and informal channels |
| Task types | Not marked | Partly marked | Every task: user, service, business rule or manual |
| Decisions | ”The employee decides” | Gateways with conditions | Gateways with conditions plus decision tables (DMN) for complex rules |
| Deadlines and SLAs | None | Mentioned in text | Timer events with annotations and their source (contract, regulation) |
| Integrations | ”Integration with the ERP” | List of systems | Pools or service tasks with direction and data scope |
| Volumes | None | Rough estimate | Cases per month, share of exception paths, peaks |
| Review | Diagram author | Department head | Walk-through with the people doing the work and review by an independent analyst |
| Format | Image or PDF | Tool file | BPMN 2.0 XML plus PDF |
The key takeaways:
- Describe the process before you describe the system. Most differences between proposals come from different ideas of the process, not of the technology.
- Aim for the analytic level. Descriptive is too general for pricing; executable is a technical design created with the vendor.
- Exceptions matter more than the main path. They hold most of the developer work and most scope disputes.
- Task types define the project boundary. A user task is a screen, a service task an integration, a manual task work outside the system.
- Legal deadlines are requirements. Fourteen days to answer a consumer complaint in Poland is a timer event the system must handle, not a margin note.
- Less is more. Above about 50 elements, the probability of a model error exceeds 50%. Split processes into sub-processes.
At ARDURA Consulting we have been building software for clients in Poland, Europe, the Middle East and the USA for more than ten years. We start every software development project by understanding the process the system is meant to support — often through BPMN diagrams prepared during discovery workshops. We see that an hour spent naming exceptions before pricing saves weeks of scope-change negotiations after signing.
If you are preparing a request for proposal for a system that supports a business process and want to check whether your documentation is ready for pricing, talk to our team. We can help model the process or review the model you already have.