Как ИИ меняет бизнес-анализ: «От запроса банка до старта разработки — в 3 раза быстрее» 

ИИ меняет роль бизнес-аналитика: производственные артефакты готовятся в 12 раз быстрее, а путь от запроса банка до старта разработки сокращается втрое.

ИИ постепенно меняет процесс бизнес-анализа в ИТ-проектах банков — от сбора и проверки требований до подготовки артефактов и перехода к разработке. По данным пилотных проектов ФИС с использованием ИИ на этапе бизнес-аналитики, производственные артефакты готовятся в 12 раз быстрее, а путь от запроса до старта разработки сокращается в 3 раза с увеличением качества документации в 5 раз. Как в новых условиях меняется роль бизнес-аналитика, какие контрольные механизмы нужны банкам и где ИИ уже даёт измеримый эффект, обсуждают Анна Вяткина, руководитель направления бизнес-анализа ФИС, и Людмила Безручко, бизнес-аналитик ФИС, эксперт в сфере управления банковскими рисками.

Анна, когда говорят об ИИ в бизнес-анализе, часто всё сводят к генерации документов. Но если смотреть на реальный процесс — от запроса бизнеса до разработки, где сегодня возникает основная потеря времени?

Я бы сказала, что больше всего времени уходит не на само написание документа. Самое сложное — договориться о деталях и удержать общую картину, пока требования уточняются. От бизнеса запрос не всегда приходит в готовом виде. Он складывается, как пазл, из встреч со стейкхолдерами, переписки, существующей документации, ограничений уже реализованных систем, требований смежных подразделений. Мы собираем этот контекст, готовим требования, выносим их на согласование — и именно на этом этапе часто начинается самое интересное.

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

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

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

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

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

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

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

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

Но здесь есть важный риск — если ускорить подготовку документа в десять раз, можно ведь и ошибку пропустить в десять раз быстрее. Как вы решаете эту проблему?

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

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

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

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

Давайте разберём конкретный пример. От заказчика приходит запрос на доработку уже работающего решения — обычный Word-документ с произвольными комментариями. Что аналитик делает с ним дальше и где в этом процессе помогает ИИ? 

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

Следующий шаг — понять, что именно может затронуть изменение. Заказчик редко приходит с формулировкой «добавьте кнопку в такой-то форме». Чаще он описывает потребность: например, нужно по-другому рассчитывать показатель. ИИ помогает разложить такой запрос на составляющие и сформировать первичную карту влияния: какие части решения стоит проверить в первую очередь — расчётную логику, роли пользователей, интерфейсы, интеграции или бизнес-процесс.

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

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

То есть получается, что граница между бизнес-анализом и разработкой начинает смещаться?

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

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

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

Для банков это особенно интересно. В кредитовании, например, изменение одного требования может затронуть целую цепочку: продуктовую логику, формы, проверки, интеграции, расчёты, тестовые сценарии. Что происходит с такими изменениями?

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

ИИ помогает сформировать первичную карту влияния изменения: сопоставить новое требование с существующими требованиями, процессами, расчётами, интерфейсами и тестовыми сценариями, подсветить связанные участки и вопросы, которые стоит дополнительно проверить. Это не заменяет экспертизу аналитика, но позволяет раньше увидеть «белые пятна» и неучтённые сценарии.

В результате мы не просто быстрее обновляем связанные материалы. Мы снижаем вероятность того, что важная зависимость обнаружится слишком поздно — уже во время UAT. А значит, экономим время бизнеса и команды на повторном прохождении полного цикла доработки.

А насколько вообще меняется качество документации? Можно ведь сделать документ кратно быстрее, но если его потом приходится долго исправлять, экономия окажется условной.

Это действительно главный критерий. Если документ подготовлен быстро, но потом команда долго исправляет ошибки, никакой экономии нет.

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

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

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

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

Получается, роль аналитика при этом не будет уменьшаться?

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

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

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

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

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

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

Если попробовать свести весь этот опыт к одной цифре, что сегодня наиболее показательно? И какой главный сдвиг произойдёт в бизнес-анализе банков в ближайшие годы?

Для бизнеса, на мой взгляд, самая важная цифра — трёхкратное ускорение принятия решений от запроса до старта разработки, потому что именно здесь эффективность отдельного аналитика превращается в эффект для всего проекта. Мне кажется, мы скоро уйдём от модели, где бизнес-анализ является долгой последовательностью ручного преобразования информации, к непрерывному контуру, в котором требования быстрее превращаются в проверяемые артефакты, а изменения оперативно внедряются в системы. Главная ценность ИИ в бизнес-анализе не в быстром написании документов, а в том, что он сокращает расстояние между бизнес-идеей и системой — оставляя ответственность за смысл и качество человеку.