Answer.

One of the key skills of a business analyst is the ability to identify and articulate the root causes of business problems (root cause analysis) before moving on to searching for solutions. A combination of methods is typically used: interviewing, facilitating brainstorming sessions, analyzing current business processes, and causal analysis (e.g., Fishbone Diagram or 5 Whys).

A business analyst must distinguish between symptoms of a problem (e.g., "low performance") and the actual cause (insufficient automation, errors in processes, lack of employee engagement). Formulating tasks involves translating identified causes into requirements: they become specific tasks for process change or solution implementation.

Key features:

Decomposing the business problem into smaller components
Using analytical and visual tools to find causes
Transforming identified causes into tasks for the IT or business team

Trick Questions.

What is the difference between a business problem and a business requirement?

A common mistake is to think they are the same. A business problem is a difficulty or barrier in an existing business process, while a business requirement is an expectation or characteristic of a future solution that is supposed to address this problem.

Can we move to solution development if the root cause is identified through interviews?

It is dangerous to rely solely on what is identified in interviews. Interviews are one of the techniques, but the results should be approached with caution and confirmed through data analysis, observation, and modeling. Only after verification should the development of solutions proceed.

Is implementing an automation system the answer to the problem of low employee motivation?

Not always. Automation can eliminate routine operations, but the cause of low motivation may lie in company culture, communication, or lack of recognition. It is important to explore the causes more deeply.

Common Mistakes and Anti-Patterns

Insufficient data collection and hasty conclusions
Confusion between symptom and root cause
Incorrect task formulation leading to non-working or too broad solutions

Real-Life Example

Negative Case:

The team assumes that the decline in sales is related to an inconvenient website interface and initiates a redesign.

Pros:

Quick response
Quite easy to implement

Cons:

The true cause was issues with the support service, and changes to the interface did not lead to improvements
Loss of budget

Positive Case:

The business analyst analyzes the sales funnel, conducts interviews with customers, and identifies that the bottleneck is in support, not in the interface. The solution is to optimize the work of the support service.