Ответ.

В исторической перспективе системные аналитики использовали ручные методы — наблюдение, интервью, анализ существующих документов. С развитием ИТ появились стандарты (например, BPMN, IDEF0, EPC), которые структурировали подход к моделированию текущих и будущих процессов.

Проблема: задача выбора подхода часто осложняется неполнотой информации, временем, сложностью предметной области и разной зрелостью бизнес-процессов. Ошибки на этом этапе приводят к неверному описанию требований, серьёзным переработкам и потере доверия к роли аналитика.

Решение: оптимальный подход — комбинировать количественные и качественные методы:

Анализировать документацию и фактическое поведение через наблюдение.
Формализовывать процессы с помощью нотаций BPMN или IDEF0 в зависимости от задачи.
Для «as-is» — собирать обратную связь с исполнителями, устраивать воркшопы.
Для «to-be» — проводить моделирование с заказчиком, заранее фиксировать ожидаемый результат и критерии успеха.
Провести gap-анализ, выявить разрывы и риски.

Ключевые особенности:

Применение нескольких техник параллельно.
Фиксация событий и альтернативных сценариев.
Постоянная верификация данных через демонстрации и короткие итерации.

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

Можно ли всегда использовать BPMN для описания всех процессов, включая технические и сложные интеграционные?

BPMN подходит только для бизнес-процессов или процедур с явной логикой. Технологичные или глубоко интеграционные сценарии лучше описывать диаграммами последовательностей (UML), архитектурными схемами или специализированными нотациями.

Достаточно ли провести интервью с одним представителем бизнес-группы, чтобы получить верную картину текущего процесса?

Нет, один источник никогда не отражает всей полноты. Требуется собрать версии от разных ролей: исполнителей, пользователей, ИТ-службы, менеджеров. Это минимизирует риск ошибок и обнаруживает скрытые концовки процесса.

Нужно ли в деталях прорабатывать будущий процесс «to-be» до каждой бизнес-операции, прежде чем проектировать ИТ-решение?

Не всегда. Излишняя детализация ведёт к бюрократии и потере гибкости. Достаточно согласовать ключевые сценарии, точки автоматизации, необходимые изменения ролей и интеграций, а детали прорабатывать итеративно в ходе реализации.

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

Описание процесса только на основании теории, без анализа реальных бизнес-сценариев
Игнорирование теневых или неявных маршрутов выполнения процесса
Избыточная детализация или, наоборот, чрезмерная обобщённость схем

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

Негативный кейс: Аналитик построил карту процесса только по регламенту, не анализируя рутинные обходы и «обходные» схемы исполнителей.

Плюсы:

Быстрое согласование документации

Минусы:

Отсутствует реальная полезность и понимание реальных проблем
ИТ-решение плохо работает в бою, требуется доработка

Положительный кейс: Аналитик провёл воркшопы, интервью, формализовал существующее и целевое состояние, показал разницу. Включил примеры реальных сценариев и их проблемы, учёл отзывы Stakeholders.