You’ve got a system going in.
The budget is approved.
Now someone asks who you need to hire.
A business analyst, a process analyst, a technical writer?
The job ads blur together.
Plenty of people use the titles interchangeably.
Hire the wrong one, you’ll still get a document.
It just won’t be the one your rollout needs.
Here’s a plain English guide to what each role does, plus how to decide.
📋 What a business analyst does
A business analyst works out what the business needs from the system.
They talk to stakeholders, then turn those conversations into requirements.
They also check the gaps between what you have now, what you’re buying.
Typical outputs.
- Business requirements
- User stories with acceptance criteria
- Gap analysis
- Stakeholder maps
- A traceable link between each requirement, then the solution
Bring one in when the question is “what should this system do?”
They protect you from buying the wrong thing, or building it without a clear brief.
🗺️ What a process analyst does
A process analyst works out how the work actually happens.
They map the current state, then design the future state.
Most use BPMN 2.0, a standard notation vendors, architects, plus auditors can all read.
Typical outputs.
- Current state process maps
- Future state process maps
- Exception paths, with volumes
- Handoff points between teams
- A list of risks found along the way
Bring one in when the question is “how does this work today, then how should it work?”
They protect you from automating a process nobody understood.
✍️ What a technical writer does
A technical writer makes sure people can actually do the work in the new system.
They turn maps, requirements, plus expert knowledge into material people follow under pressure.
Typical outputs.
- Work instructions
- Standard operating procedures
- Quick reference guides
- Knowledge base articles
- Training materials
Bring one in when the question is “how will 400 people learn this?”
They protect you from a smooth go live followed by a flood of support tickets.
🔗 Where the roles overlap
The overlap is where programs get messy.
A business analyst might sketch a process, because it’s quicker than waiting.
A process analyst might write procedures, because nobody else is available.
A technical writer might end up asking the questions a business analyst should have asked.
None of that is wrong.
It just means gaps open between the roles.
The classic gap looks like this.
The requirements say “approve the claim”.
The process map shows an approval task.
The user guide says “click Approve”.
Nobody has asked who approves when the usual person is on leave.
That one question can sink a week 1 support queue.
⚖️ How to decide
A simple rule of thumb.
Start with your biggest unknown.
- Not sure what to buy or build? Start with a business analyst
- Not sure how work happens today? Start with a process analyst
- System is chosen, people need to use it? Start with a technical writer
Most programs need all 3 at some point.
Small ones often can’t afford 3 separate hires.
That’s where one experienced person covering all 3 earns their keep.
🤝 The skill that matters more than the title
Titles describe what someone produces.
They say nothing about whether the work will be accurate.
Accuracy depends on getting busy people to tell the truth.
Ask any candidate how they’d do that.
Good answers sound like this.
They turn up with a rough draft, never a blank page.
They ask specific questions, not general ones.
They book 20 minutes, not an hour.
They follow up privately with anyone who stayed quiet in the workshop.
Weak answers focus only on templates.
Notation is learnable in a few weeks.
Trust takes longer, plus it decides what ends up in the document.
✅ If you’re still not sure
You don’t need to work it out alone.
A short conversation about your system, your timeline, then what’s worrying you usually makes the answer obvious.
If you’d like to talk it through, book a free 30 minute call.
You’ll leave with a plan in plain language, whether or not we end up working together.
About the author
Aiver Ilaya is an IT consultant based in Melbourne. For 19 years he’s worked on enterprise digital transformation programs. His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation. 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.
His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design. He has worked on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
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
