Business Analyst From Questions to Real Impact

A team asks for a new system because its current process is slow. Another asks for a dashboard because it cannot explain its results. Both requests may be reasonable, but neither tells us enough to choose a solution. What is causing the difficulty? Who is affected? What would a better outcome look like?
This is where a business analyst contributes. The work connects people’s experiences with evidence, clear requirements and practical decisions. A useful way to remember that contribution is through the letters in ANALYST: Ask, Needs, Analyse, Learn, Yield, Solutions and Test. Each represents a habit that helps move a conversation towards a useful result.
Consider an illustrative workplace example: employees are frustrated by slow expense reimbursements, and a manager proposes replacing the expense system. The following steps show how an analyst could explore that request. The example describes a realistic situation, rather than a reported case or measured result.

A - Ask the right questions

Start by understanding the experience behind the request. Ask employees to walk through a recent claim. Talk with approvers and the finance team. Where does the claim wait? What information is missing? Which situations are most difficult? What do people currently do to get around the problem?

A broad statement such as ‘the system is too slow’ can hide several different issues. Someone may mean that uploading a receipt takes too long. Someone else may mean that approval takes days. Asking for concrete examples helps people describe what is actually happening. Listen first, then check that you have understood before proposing an answer.

N - Narrow down requirements

The next task is to clarify what people need and what matters most. A request names a possible solution; a requirement describes something the change must achieve or support. In the expense example, needs might include clear approval ownership, a way to see claim status and fewer submissions returned for missing information.

Agree priorities with the people responsible for the outcome. Which needs are essential? Which can wait? What rules or constraints must be respected? Make requirements specific enough to check. ‘Improve visibility’ is vague. ‘Employees can see the current status of their submitted claim and the team responsible for the next action’ gives everyone a clearer basis for discussion and testing.

A - Analyse the data

Use evidence to understand the problem more closely. For expense claims, you could examine submission dates, approval dates, returned claims and reasons for rework. Map the steps alongside the data so you can see where delays occur. Compare straightforward claims with more complex ones rather than assuming they follow the same path.

Check the quality of the information before drawing conclusions. Are dates recorded consistently? Are some claims missing from the records? A long average turnaround time does not, by itself, show what caused the delay. If claims appear to wait mainly for approval, investigate that finding with the people involved. Data and conversation should help you test an explanation, not simply confirm your first assumption.

L - Learn continuously

An analyst needs to keep learning about the organisation, its customers, its rules and the tools it uses. In this example, understanding approval responsibilities and how staff use the system may be more useful than immediately studying replacement products. Ask colleagues to explain unfamiliar terms and check your understanding against actual work.

Learning also means revising your view. You might begin with a technical concern and discover that unclear responsibilities contribute to the problem. Treat that discovery as progress. The aim is to understand enough to recommend a useful change, even when the evidence takes you in a different direction.

Y - Yield valuable insights

An insight explains why a finding matters and what decision it could inform. Listing delayed claims is useful information. Explaining that a recurring handover leaves claims without a clear owner gives the team something more actionable, provided the evidence supports it.

Present the finding in everyday language: what you observed, who it affects and what remains uncertain. In the expense example, you might recommend investigating approval routing before committing to a replacement system. Keep the recommendation proportionate to the evidence. If the data is incomplete, say what needs to be checked next.

S - Suggest solutions clearly

Offer practical options rather than presenting the first idea as the only answer. The expense team could consider clearer submission guidance, revised approval routing, changes to the existing system or a replacement. Explain which problem each option addresses, along with its likely effort, cost, risks and effect on staff.

Make trade-offs visible. Updating guidance might reduce missing information but do little about approval delays. A system replacement might address several issues but require migration and training. The analyst helps decision-makers compare these choices. The people with the appropriate authority decide what to proceed with.

T - Test and validate

Check both whether the change works as intended and whether it helps people. Before release, use realistic scenarios with employees, approvers and finance staff. Test ordinary claims as well as exceptions, such as an absent approver, an incomplete receipt or a claim returned for correction.

After implementation, review the outcome against the starting point and the agreed measures. Are claims moving through the process more quickly? Has rework reduced? Can staff understand the status without chasing someone? Gather feedback alongside the figures. A technically correct feature may still be confusing to use. Refine the change where the evidence shows a remaining problem.

Keep the outcome in view

These habits are connected, and they do not always happen in a straight line. Testing may reveal a missing requirement. Analysis may lead to another conversation. A suggested solution may expose a constraint that requires more learning.

For your next assignment, begin with three questions: what problem are we trying to solve, what evidence will help us understand it, and how will we know the change has helped? Keep returning to those questions as the work develops. The value of business analysis becomes visible when better understanding leads to decisions and changes that people can use.