← Предыдущая статья

В начале проекта часто звучит еще не оформленное требование, а рабочая проблема или пожелание.

Заказчик говорит, что форма неудобна. Что отчет не помогает управлять процессом. Что старую систему нужно заменить. Что пользователи привыкли работать определенным образом. Что продукт вроде бы установлен, но реальные сценарии после запуска начинают отваливаться один за другим.

Из этого еще не получается требование.

Сначала важно понять, в чем именно проблема. Что мешает работать? Почему запрос возник именно сейчас? Как устроен процесс? Что нельзя потерять при замене системы? Где ограничения продукта? Какие действия пользователи считают очевидными, хотя они очевидны только внутри одного коллектива или даже только для одного специалиста?

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

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

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

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

Отсюда главный вопрос: кто в проекте отвечает за то, чтобы требование не оторвалось от причины, по которой оно возникло?

В проектах импортозамещения и развития корпоративного ПО эту роль все чаще приходится брать на себя бизнес-аналитику.

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

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

Если этому не уделить должного внимания, проект начнет жить в режиме испорченного телефона. Только вместо веселой детской игры получится тяжелое промышленное внедрение: деньги уже потрачены, сроки горят, люди нервничают, а спор идет даже не о задаче, а о том, кто что имел в виду.

Факты

По итогам АКПО-Конф 2026

В программе сессии «На пути к технологическому суверенитету: как бизнес-аналитики перестраивают российский ИТ-ландшафт» бизнес-анализ был связан не только с формирующейся на наших глазах профессией. Вопрос ставился шире: технологическое лидерство, профстандарты, язык заказчиков, диалог разработчиков ПО и аналитиков, подготовка специалистов, консолидация требований крупного бизнеса.

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

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

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

После этого разговор коснулся характера работы бизнес-аналитика. Ему недостаточно уметь задавать вопросы и пользоваться техниками описания требований. Ему важно понимать процессы заказчика и разговаривать с ним на одном языке, но также ясно доносить задачу команде разработки и хотя бы в общих чертах представлять, как решение будет устроено. Иначе он превращается в курьера, который «доставил задачу» и решил, что дело сделано.

Один участник задался вопросами: «зачем нужна работа бизнес-аналитика» и «как это приносит деньги». Это важный поворот. Бизнес-аналитик работает не только с формулировкой требования. Он должен удерживать деловой, предпринимательский смысл запроса: какую пользу должно принести изменение, какие потери оно должно устранить, какие риски должно снизить. Если он этого не понимает, он становится оформителем пожеланий, а не специалистом, который проверяет запрос на связь с реальной задачей компании.

Со стороны разработчика продукта прозвучала другая проблема. Обратная связь заказчика без бизнес-анализа легко превращается в список разрозненных пожеланий. А список пожеланий еще не говорит, какую задачу должен решить продукт. Заказчики тоже не всегда понимают, зачем им бизнес-аналитики. В результате они приходят с готовой простыней «что сделать», но без ясного понимания «зачем».

В обсуждении прозвучал показательный проектный эпизод. У крупного заказчика внедряли замену почтовой системы. Но в ходе запуска выяснилось, что прежний почтовый контур в реальной работе выполнял гораздо больше функций, чем можно было предположить по названию: через него проходили массовые рассылки на 100 тыс. плюс пользователей, а часть рабочих сценариев фактически напоминала задачи CRM, ERP и внутренних систем взаимодействия. После перехода на новый продукт часть этих сценариев начала ломаться, и продукт пришлось дорабатывать уже после запуска.

Этот пример был приведен не для поиска виновных. Участник обсуждения прямо признался, что ситуация в этой истории чуть изменена для большей наглядности. Но сам сигнал точный: при замене корпоративного решения нельзя опираться только на формальный класс системы и буквально выполнять то, что заказчик сумел сформулировать. Вместо этого важнее понять, какую реальную работу система выполняет, какие скрытые сценарии на ней завязаны и что пользователи считают само собой разумеющимся.

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

Что видно по российским реалиям

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

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

Формально профессия уже описана. Профессиональный стандарт «Бизнес-аналитик», утвержденный приказом Минтруда России №821н, опубликован на официальном портале правовых актов. В нем бизнес-анализ связан с выявлением бизнес-проблем, выяснением потребностей заинтересованных сторон, обоснованием решений и обеспечением проведения изменений в организации (Официальное опубликование правовых актов, приказ Минтруда России №821н).

Но профессиональный стандарт сам по себе не доводит задачу до результата. Он задает рамку профессии, а дальше начинается практика: кто пришел к заказчику, кто понял процесс, кто отделил потребность от случайного пожелания, кто объяснил ограничение продукта, кто донес требование до разработки, кто вернулся к заказчику и проверил, что решение попало в боль, а не только в строку документа.

В российских проектах импортозамещения эта цепочка особенно уязвима: одновременно меняются продукты, разработчики ПО, интеграторы, регламенты, банковские условия, правила поддержки и привычные контуры эксплуатации. Разработчик продукта развивает платформу, заказчик меняет контур, интегратор пытается приземлить решение, бизнес хочет не потерять эффективность, ИТ хочет не уронить эксплуатацию. Если никто не удерживает исходную задачу и решение в одной логике, система все еще может соответствовать документу, но далеко не всегда будет соответствовать тому, ради чего проект вообще затевался.

Что подсказывает внешний SAP-фон

Опыт SAP здесь полезен не как рецепт, а как напоминание: в крупных ERP-проектах требование живет только тогда, когда оно связано с процессом, ролями, стандартом, выявленным расхождением и проверкой.

В SAP Activate во время семинаров по сопоставлению со стандартной функциональностью — fit-to-standard workshops — требования фиксируются там, где стандартная функциональность SAP S/4HANA Cloud сопоставляется с конкретными потребностями заказчика. SAP Learning указывает, что такие требования помогают выявлять расхождения между стандартной функциональностью и потребностями бизнеса, а фиксировать их рекомендуется по отдельности в SAP Cloud ALM (SAP Learning, Conducting Fit-to-Standard Workshops).

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

BABOK Guide от IIBA описывает бизнес-анализ как практику, которая помогает организациям проводить изменения через определение потребностей и рекомендацию решений, создающих ценность для заинтересованных сторон. Там же бизнес-анализ представлен как область с общим языком, задачами, компетенциями, техниками и подходами (IIBA, Business Analysis Global Standards of Practice).

Для российской аудитории это не внешний эталон, который нужно копировать. Это полезный фон: зрелый бизнес-анализ начинается там, где требование перестает быть фразой и становится управляемым объектом. У него есть источник, причина, границы, связи, критерии проверки и последствия.

Редакционное наблюдение

Если сложить эти фрагменты, видно главное: бизнес-аналитик в проектах импортозамещения оказывается не между двумя, а между большим числом миров.

Бизнес говорит на языке проблем, денег, сроков, привычек и ответственности.
ИТ говорит на языке архитектуры, интеграций, данных, безопасности и сопровождения.
Разработчик продукта говорит на языке платформы, дорожной карты, стандартной функциональности и ограничений решения.
Интегратор говорит на языке внедрения, настроек, доработок, рисков и трудоемкости.
Пользователь часто говорит проще всех: «раньше я нажимал сюда, а теперь работать стало трудно».

Все они по-своему правы. И при этом все они могут не слышать друг друга.

Роль бизнес-аналитика в такой ситуации — не просто перевести слова. Слова перевести мало. Нужно не дать требованию оторваться от причины запроса: зачем это нужно, кому это нужно, как сейчас устроен процесс, что изменится после внедрения, какой риск закрываем, какой эффект ожидаем, где границы требования и как поймем, что оно выполнено.

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

Попытка объяснения

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

Меняются продукты, платформы, разработчики ПО, интеграторы, регламенты, банковские условия, правила поддержки и привычные контуры. При этом бизнес не готов ждать, пока все окончательно устаканится. Ему нужно работать сейчас: закрывать период, продавать, закупать, производить, платить, считать, отчитываться.

В такой ситуации требование становится не заявкой, а подобием коммунальной кухни.

Бизнес хочет сохранить рабочий результат.
ИТ хочет встроить решение в архитектуру.
Разработчик продукта боится сломать логику платформы.
Интегратор хочет уложиться в сроки и бюджет.
Служба безопасности опасается еще одной дыры в контуре.
Пользователь мечтает прекратить страдания хотя бы к четвергу.

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

Почему возник запрос?
Какую проблему он закрывает?
Какой процесс за ним стоит?
Кого он затрагивает?
Что будет, если сделать буквально?
Что будет, если не сделать?
Как проверить, что решение работает?
Как понять, что все вот-вот накроется и что с этим делать?
Где требование должно стать настройкой, где доработкой, а где изменением процесса?

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

Гипотеза

В проектах импортозамещения и развития корпоративного ПО бизнес-аналитик становится зрелым не тогда, когда он просто собирает требования, а когда он доводит исходную задачу до результата без смысловых потерь.

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

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

А кто у вас отвечает за то, чтобы требование не потеряло связь с исходной задачей до конца проекта? Бизнес-аналитик, системный аналитик, архитектор, владелец продукта, интегратор, ключевой пользователь, руководитель проекта — или связь каждый раз удерживает тот, кто дольше всех остается в переписке после совещания? Где она чаще всего рвется: на первом разговоре с заказчиком, при постановке задачи, в архитектуре, в разработке, при проверке, на приемке или уже после запуска? Как вы это пережили?

Пишите на y.nechitaylov@sappro.ru, в комментариях к соответствующим постам в сообществе в ВК или в комментариях под этими материалами на sappro.ru.

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

Продолжение следует.

Автор

Юрий Нечитайлов, главный редактор SAP Professional Journal Россия