There’s a question that comes up early on most programs, usually as a scheduling problem rather than a role question.
Who’s actually documenting the process?
The business analyst assumes it’s covered.
The change team thinks it’s a project deliverable.
The process owner assumed someone did it years ago.
Meanwhile the technical writer has been booked to write user guides for a system that hasn’t been designed yet.
That gap is worth sorting out properly, because process documentation involves at least 3 roles doing quite different work.
🎭 The roles that overlap
Process analyst or business analyst.
Builds the current state, designs the future state, models it in BPMN 2.0.
Owns the accuracy of the flow, the decision logic, the handoffs.
Process owner.
Accountable for the process actually running.
Approves changes, resolves disputes between teams, lives with the outcome.
Technical writer.
Turns all of that into material people can follow while doing their job.
Owns whether a human being can understand it under pressure.
Those aren’t the same skill.
An analyst can produce a technically correct map that reads like a circuit diagram.
A writer can produce beautifully clear instructions describing a process nobody validated.
You need both.
✍️ Where the writer adds value in process work
The instinct is to bring writers in at the end, once the process is settled.
That’s a waste of the most useful thing they do, which is noticing what’s missing.
Writers sit slightly outside the system.
Close enough to follow the explanation, far enough to see when 1 step doesn’t connect to the next.
What that produces during mapping.
- Ambiguity caught early, since “approved by management” survives conversation but not a numbered procedure
- Inconsistent terminology surfaced, because writers notice 4 words for the same object
- Missing prerequisites identified, as the map assumes access nobody specified
- Exceptions probed, because writers keep asking what happens when it fails
- Gaps between the map, plus what a reader would actually need to act
None of that is writing work.
It’s noticing work, which happens to be what writers are trained for.
🔗 The layer only a writer builds
There’s a piece of process documentation that consistently gets skipped.
A BPMN 2.0 map shows a task called “Assess claim”.
For the person doing it, that’s 4 screens, a lookup in another system, plus a decision about which category applies.
The map doesn’t cover any of that, nor should it, since a process map isn’t an interface specification.
The work instruction sitting underneath the task is the writer’s territory.
Building that layer well means linking each task on the map to the instruction behind it, using stable task IDs rather than task names.
Names change constantly during a rollout.
IDs survive.
Do that properly, then somebody can move from the flow to the detail in 1 click, which is the whole point of the exercise.
🤝 How the roles should work together
A sequence that works.
- Analyst gathers accounts, builds a draft current state map
- Writer joins the validation sessions, asking the reader-facing questions
- Analyst finalises the map, owning decision logic plus handoffs
- Process owner approves it, resolving disagreements between teams
- Writer builds the work instructions beneath each task
- Writer decides where everything lives, plus how people search for it
- Process owner takes ownership at handover, with a review date set
Notice the writer appears in the middle, not just at the end.
That single change improves both artefacts.
⚖️ Who owns what, plainly
Simplest way to divide it.
The analyst owns whether the map is correct.
The process owner owns whether the process is right.
The writer owns whether anybody can follow it.
Confusion between those 3 is where documentation projects go wrong.
An analyst asked to write user guides produces something accurate that reads like a specification.
A writer asked to model a process produces something readable that hasn’t been validated with anyone.
Neither person is failing, they’re just being asked for the wrong output.
✅ The practical answer
So who documents business processes?
All 3 roles, in different layers.
The map belongs to the analyst.
The decisions belong to the process owner.
Everything the end user reads belongs to the writer.
Get that agreed in the first fortnight of a program, then most of the usual confusion disappears before it costs anyone a week.
About the author
For 19 years Aiver has worked on enterprise digital transformation programs.
These are multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
He is an IT consultant based in Melbourne.
His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation.
His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design.
He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.
He has run his own consultancy for 12 years and works with a small number of clients at a time.
Available for remote and hybrid contracts.
alisodigital.com
