Every company has processes, whether anyone has written them down or not. An order is accepted, a repair is done, an invoice goes out – and most of it lives in people’s heads. Process mapping means putting this on paper or on screen, so that others can see it, discuss it and improve it.
Two questions usually come up first: who should do the mapping, and which flowchart method should you pick? The short answers are: the people who do the work, and the simplest method that gets the job done. The rest of this article explains why and shows how to record your first process.
Who can map processes?
You do not need to be a process analyst. Mapping is mostly about asking good questions and drawing what you hear. The person who does the work every day knows it better than any outside expert. What they often lack is a simple, shared way to write it down.
In practice, a good mapping session involves four roles:
The person who does the work – describes what really happens, including the workarounds nobody wrote down.
The process owner – usually a manager. Decides what the process should achieve and approves the final version.
A facilitator – a quality manager, an operations lead or simply someone who keeps the conversation structured. Patience matters more than a certificate.
A neighbour – someone from the step before or after, who checks that the handovers make sense.
In a small firm, one person may play two or three of these roles, and that is fine. Start with one process, one or two people and about an hour of time. A rough first version that the team recognises as true is worth more than a polished diagram nobody agrees with.
Which flowchart method to start with
For a beginner, the best starting point is a plain flowchart. Four shapes are enough to describe almost any everyday process:
an oval for the start and the end,
a rectangle for an activity (“Prepare quote”),
a diamond for a decision with “yes” and “no” branches,
an arrow to show what follows what.
Once the basic flow is on the page, add the question “who does this?” to each step. That turns a simple flowchart into a so-called swimlane diagram, where each role or department has its own row. You do not need to learn anything new – you just add one more piece of information.
Approach | Good for | Watch out for |
|---|---|---|
Plain flowchart | Your first map; explaining a process to colleagues in minutes | Can hide who is responsible for each step |
Flowchart with roles (swimlanes) | Processes where work passes between people or departments | Too many lanes make the picture hard to read |
BPMN | Precise models, shared with specialists, more complex processes with events and exceptions | Larger set of symbols; easy to overcomplicate a first attempt |
BPMN (Business Process Model and Notation) is a standardised notation with a fixed set of symbols for events, decisions and message flows. It is a powerful tool, but you do not need it on day one. If your needs grow, you can move from a simple flowchart to BPMN later, and the map you drew first will still be a good starting point.
If you work in Stepiora, the flowchart is drawn directly inside the process, and you choose IT systems and job positions from your company’s own lists instead of retyping them each time. BPMN 2.0 is there for those who need it. You can also try the free flowchart editor and BPMN modeler on the web without registering.
How to record a process in six steps
Your first process map
- Choose one process and set its boundariesWrite down where it starts and where it ends, for example from “customer request received” to “invoice paid”.
- Invite the right peopleAsk the person who does the work, the owner and someone from the neighbouring step.
- List the steps in plain wordsUse a verb and an object – “check stock”, “send offer” – and keep each step short.
- Draw the flow and mark the decisionsConnect the steps with arrows and add a diamond wherever the path can split.
- Add who does whatFor each step, note the job position, the IT system used and the document produced.
- Walk through it and correct itRead the map aloud with the team and fix everything that does not match reality.
A quick example
Imagine a small service company that repairs household appliances. The process starts with “customer reports a fault” and ends with “invoice paid”. Between them are steps such as recording the request, diagnosing the fault, a decision (“Is the part in stock?”), repair, handover and invoicing.
The technician will quickly point out that customers often call back after a week and that nobody records this. That is exactly the kind of insight a map brings: a missing step becomes visible, and you can decide whether to add it.
Add responsibilities
When the flow is right, decide who is responsible for each step. A common tool is RACI, a simple table that marks for every step who is Responsible for doing it, who is Accountable for the result, who must be Consulted and who is only Informed.
Stepiora lets you set RACI for every step, and the responsibility belongs to the job position, not to a particular person. When someone leaves or a role is covered by a colleague, the process does not lose its owner. The same idea works on paper too: write positions, not names.
Common mistakes and how to avoid them
Drawing the ideal instead of the real process. First record what actually happens. Improvements come in the next round.
Going into too much detail. If a map has more than a few dozen steps, split it into smaller processes.
Mapping alone at a desk. A manager’s picture of the process and the team’s experience often differ a lot.
Using names instead of positions. People change roles; positions stay.
Trying to map the whole company at once. Pick the one process that causes the most trouble or runs most often.
Never coming back to it. A map that is not reviewed becomes outdated and loses its value.
Summary
Anyone who knows the work can take part in process mapping, and a process analyst is not required. Start with a plain flowchart, add who does what, and move to BPMN only when you really need more precision. Choose one process, map it with the people who run it, check it against reality and agree who looks after it. That is the foundation of everyday process management.