Ответ.

История вопроса:

Автоматизация нестандартных или только формирующихся бизнес-процессов долгое время считалась сложной задачей из-за отсутствия четко регламентированных сценариев и высокой изменчивости. Традиционные подходы системного анализа не всегда подходят, и требуется более гибкая методология.

Проблема:

Главная проблема при работе с такими процессами — их динамичность: описание на старте часто не отражает сути части операций, а требования клиентов могут быстро меняться или уточняться по ходу работы.

Решение:

Чтобы корректно выявлять и описывать требования, применяют итеративные подходы (Agile, Lean), собирают данные через наблюдение и быстрые прототипы, активно вовлекают пользователей (например, через воркшопы) и фиксируют требования в формате user stories, дополняя их живой документацией в Confluence, Miro, Figma и т.п. Ключевые особенности подхода:

Прием непрерывной обратной связи от пользователя и команды бизнеса
Использование прототипирования и быстрых MVP для конкретизации размытых сценариев
Инкрементальное уточнение требований: фиксируем только то, что жизнеспособно и повторяемо

Вопросы с подвохом.

Одинаковы ли требования в начале и в конце анализа нестабильного процесса?

Нет, по итогам анализа требования меняются: часть устаревает, а часть формализуется лишь после применения прототипов в реальной практике.

Нужно ли фиксировать весь бизнес-процесс сразу, если он меняется?

Нет, нужно фиксировать только проверенные и работающие фрагменты, остальное — оставлять как гипотезы или уточнять по мере развития.

Следует ли выбирать только одни средствами фиксации требований?

Нет, важно использовать несколько каналов: стендап-доски, электронные черновики, прототипы — для разных аудиторий и стадий.

Типовые ошибки и анти-паттерны

Попытка детализировать все аспекты заранее (waterfall)
Игнорирование обратной связи с пользователем
Работа исключительно с уже утвержденной документацией или только устными требованиями, без живых примеров

Пример из жизни

Негативный кейс:

Компания решила автоматизировать процесс, который ещё окончательно не устоялся. Аналитик описал процесс строго по схеме, зафиксировал все, что рассказали сотрудники. После запуска процесс быстро изменился, а система не отвечала новым реалиям.

Плюсы:

Быстро проведена интеграция существующих схем

Минусы:

Процесс автоматизирован лишь частично, большинство изменений не учтено, дорогостоящие доработки

Положительный кейс:

Аналитик осуществлял частичную фиксацию только стабильных этапов, строил MVP с минимальным набором функций, собирал фидбек, дорабатывал требования вместе с бизнесом, оставляя пространство для изменений.