Answer

Historically, systems analysts often started their work with an in-depth analysis of the company's business processes. This allowed them to understand where and how the information system could automate or optimize the organization's activities. However, the boundaries between business process analysis and technical design often blur.

Key Features:

• Business process description is aimed at identifying and formalizing the organization's activities as a system, without considering the details of IT implementation.
• Information system design begins after requirements are formed, and involves working out the architecture, interfaces, integrations, and data formats.
• It is important to separate these stages: first, the analyst determines "what to do," then — "how to do it."

Historical Background

Previously, the boundary between these stages was clearer: the business analyst was responsible for modeling processes, and the systems analyst was responsible for translating requirements into technical specifications. In modern practice, these tasks are often mixed.

Problem

Many analysts start designing the system before completely analyzing the processes, leading to incorrect requirements definition and excessive technical detailing.

Solution

Clearly separate domain analysis from design, use BPMN and EPC for process description, and for design — UML, data flow diagrams (DFD), etc.

Trick Questions.

What is more important — to analyze business processes or to design the system?

One cannot single out one thing: process analysis is needed to develop correct requirements, and design is needed for their implementation. These are sequential stages.

Can the same diagrams be used for process description and system design?

No, BPMN/EPC are applicable for processes, while UML/DFD are for structural or object-oriented analysis and design.

In what case can business processes be left unmodeled?

Only if the project is small, and they are already fully formalized in documents or standards. In most cases, modeling is necessary.

Typical Mistakes and Anti-Patterns

• Premature detailed transition to the data schema, without understanding the business tasks.
• Mixing process description and technical solutions.
• Ignoring the interests of end users.

Real-Life Example

Negative Case:
The analyst immediately started drawing the database schema and services, without studying how employees work and what they need. Pros: quick implementation, everyone is happy with the first version.
Cons: the system does not solve real tasks, users are dissatisfied, and rework was needed.

Positive Case:
The analyst first conducted a series of interviews with employees, built BPMN, and then moved on to designing the API and database. Pros: requirements are clear, the system covers real processes.
Cons: longer project start, higher analytical expenses.