В компании уже выбрали информационную систему для внедрения.

Подрядчика почти нашли, бюджет примерно согласовали, руководитель проекта в голове уже живёт в светлом будущем.

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

Потом кто-то вспоминает, что для внедрения нужны требования.

И зовут аналитика.

Не чтобы разобраться, что именно должно измениться в работе компании. Не чтобы проверить, почему текущие бизнес-процессы ломаются. Не чтобы понять, какую задачу компании вообще нужно решить.

А чтобы описать требования к уже выбранному решению.

На этом месте бизнес-анализ часто становится не анализом, а аккуратной упаковкой чужого выбора.

В Global State of Business Analysis Report 2026 IIBA собрала ответы 2 120 специалистов из 122 стран. 81% респондентов отмечают, что бизнес-анализ формально признан в их организациях. IIBA говорит о вовлечении аналитиков в принятие решений и формулирование проблем на ранних стадиях. И одновременно отмечает: ясность роли и раннее вовлечение по-прежнему остаются среди основных барьеров.

При этом бизнес-анализ может быть признан, аналитик может быть в проекте, требования могут быть написаны.

Вопрос в том, в какой момент он появляется.

Потому что после выбора системы многие вопросы становятся неудобными.

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

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

После решения те же вопросы начинают портить настроение.

Проект уже бодро смотрит в сторону договора, а тут кто-то приходит и спрашивает: а почему мы вообще решили, что нам нужна именно эта система?

Неудобный человек. Почти саботажник, если смотреть из презентации.

Плохо написанные требования - проблема.

Хорошо написанные требования к непроверенному решению могут стоить гораздо дороже.

Документ будет выглядеть прилично. Таблица будет заполнена. Формулировки будут ровные. Можно даже сделать раздел «цели проекта», чтобы всем было спокойнее.

Только хорошее описание не спасает решение, которое стало ответом раньше, чем компания нормально сформулировала вопрос.

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

Решение должно быть результатом анализа.

А не его исходным условием.

Перед следующим проектом автоматизации я бы точно задал эти вопросы.

Мы действительно нашли решение проблемы? Или просто очень хорошо описываем решение, которое уже успели выбрать?

Ещё больше обо мне | sergey-suslov.ru