Answer.

Historically, systems analysts used manual methods — observation, interviews, analysis of existing documentation. With the development of IT, standards emerged (e.g., BPMN, IDEF0, EPC), which structured the approach to modeling current and future processes.

Problem: The choice of approach is often complicated by incomplete information, time constraints, complexity of the subject area, and varying maturity of business processes. Mistakes at this stage lead to inaccurate requirement descriptions, significant rework, and loss of trust in the analyst's role.

Solution: The optimal approach is to combine quantitative and qualitative methods:

Analyze documentation and actual behavior through observation.
Formalize processes using BPMN or IDEF0 notations depending on the task.
For 'as-is' — gather feedback from performers, organize workshops.
For 'to-be' — conduct modeling with the client, fixing expected results and success criteria in advance.
Conduct gap analysis to identify gaps and risks.

Key features:

Use multiple techniques in parallel.
Document events and alternative scenarios.
Continuous data verification through demonstrations and short iterations.

Trick Questions.

Can BPMN always be used to describe all processes, including technical and complex integration ones?

BPMN is suitable only for business processes or procedures with clear logic. Technical or deeply integrated scenarios are better described with sequence diagrams (UML), architectural diagrams, or specialized notations.

Is it enough to interview one representative from the business group to get an accurate picture of the current process?

No, a single source never reflects the full picture. It is necessary to gather versions from different roles: performers, users, IT staff, managers. This minimizes the risk of errors and uncovers hidden endings of the process.

Should the future 'to-be' process be detailed down to each business operation before designing the IT solution?

Not always. Excessive detailing leads to bureaucracy and loss of flexibility. It is sufficient to agree on key scenarios, automation points, necessary role changes, and integrations, while details can be worked out iteratively during implementation.

Typical Mistakes and Anti-Patterns

Describing the process solely based on theory without analyzing real business scenarios
Ignoring shadow or implicit execution paths of the process
Excessive detailing or, conversely, overly general representations of diagrams

Real-Life Example

Negative Case: The analyst built the process map solely based on regulations, without analyzing routine workarounds and 'bypass' schemes of the performers.

Pros:

Quick agreement on documentation

Cons:

Lacks real usefulness and understanding of actual problems
The IT solution poorly performs in real-world situations, requiring rewrites

Positive Case: The analyst conducted workshops, interviews, formalized the current and target state, illustrated the differences. Included examples of real scenarios and their issues, considered feedback from stakeholders.