От сборщика требований к бизнес-партнеру: как меняется роль аналитика

Привет, Хабр!

На связи команда Дирекции автоматизации девелопмента ПИК — Маргарита Золотых и Ольга Абражевич. В этой статье нам хотелось бы обсудить, какие аналитики будут востребованы в реалиях 2026 года и как найти себя в профессии тем, кто вырос до позиции Senior. С одной стороны, однотипное описание требований и фиксация чужих решений аналитикам становятся неинтересными. С другой стороны, компаниям с приходом доступных ИИ-инструментов и в тренде на оптимизацию бюджетов такой посредник становится нужен все меньше. 

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

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

Кейс: изменение ставки НДС — скучная задача или простор для креатива? 

Осенью 2025 года в информационном поле появилась информация о возможном изменении законодательства и переходе на ставку НДС 22%. Это выглядело как чувствительное изменение, поскольку наши системы, в которых автоматизирован данный процесс, «самописные», и типового решения, которое мы можем применить (как, например, в 1С), просто не существует. В чем же сложность?

Строительные договоры имеют длинную историю жизни, где на протяжении двух и более лет подписываются и корректируются десятки актов и заключаются уточняющие дополнительные соглашения. Договор может быть заключен на условную сумму 100 рублей в 2023 году. Далее каждый месяц к договору подрядчик может подавать акты для получения денег за фактически выполненные работы. В каждом акте и договоре есть рассчитанная сумма НДС по ставке 20%. Для наглядности представим жизненный цикл договора и актов в таблице ниже:

В примере выше на момент 1 января у нас сформируется такая ситуация: сумма по договору 150 рублей с НДС 20%, сумма актов, закрытых по ставке 20%, составила 80 рублей. Таким образом, на ставку 22% необходимо перенести только те объемы, которые не были закрыты актами на общую сумму 70 рублей. Техническая формулировка теперь — «зафиксировать факт выполнения по старой ставке и перенести незакрытые остатки по договору на новую ставку, не потеряв связь между документами и не остановив подачу актов». 

Две стратегии аналитика: ждать задачу или прийти с решением

В нашем кейсе мы видим два основных подхода, в которых может жить аналитик, — быть исполнителем или быть партнером. 

1.Стратегия «заказчик -> исполнитель»

Аналитик может ждать задачу и/или проработанную методологию поведения систем от бизнеса. Формально аналитик сделает все правильно, поскольку заказчик для нас — бизнес. И если нет запроса от бизнеса, то и нет задачи. 

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

2. Стратегия «бизнес-партнер»

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

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

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

Техническое решение по кейсу

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

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

1. Конструктор цен (КЦ) — «сметный калькулятор», самописная веб-система для первичного расчета смет на строительные работы и сумм НДС по всей группе компаний ПИК.

2. Система подачи актов (ПИК2В) — самописная веб-система, используется подрядчиками для фиксации фактически выполненных работ и инициации актов.

3. АУД — «мозг» нашего договорного процесса и фундамент остальных сметно-договорных процессов ПИК — система для учета и согласования смет и расчета сумм, доступных к актированию по договору.

4. Система согласования (ЭДО) — обеспечивает юридическое подписание документов.

Ниже общий процесс заключения договоров и актирования на схеме:

 

Какие у нас есть сложности?

1. Проблема номер один — процесс изменения остатков по договору динамический и рассчитывается исходя из статуса поданного акта и договора. Мы поставим в системе АУД запрет на подачу новых актов и смет на согласование. А также в заранее условленную дату отклоним все акты и договоры, созданные по ставке 20%. Таким образом, мы понимаем, что остатки по договорам по ставке 20% зафиксированы и больше изменяться не будут.

2. Вторая проблема — сметный калькулятор КЦ хранит ставку НДС не в строках сметы, а в шапке. Таким образом, две ставки в одной смете не могут быть выбраны. Мы придумали в сметном калькуляторе такое понятие, как «смета на факт выполнения по ставке 20» и «смета на остаток по договору по ставке 22». Технически это две отдельные автономные сметы, которые связаны между собой реквизитом в БД. То есть в смете на остаток лежит ссылка на смету с фактом. При создании допсоглашений к смете на остатки ссылка на расчет с фактом останется той же самой. В таком решении остается вопрос: если в КЦ это две технически отдельных сметы, то как они «склеятся» для подписания договора в единую? Аналитики предложили собирать итоговую смету непосредственно перед подписанием: в АУД передается и смета на остатки, и смета на факт выполнения, а уже АУД перекладывает ставку НДС из шапки в строки и хранит значения ставки НДС. Сами суммы НДС для каждой строки при этом считает КЦ.

3. Третья проблема — акты (факт выполнения) создаются в одной системе, сметы — в другой. Как нам получить в сметном калькуляторе остатки по договорам? Вернемся снова на схему процесса. И опять — АУД, имеет всю необходимую информацию — саму смету из КЦ, статусы договоров, акты, статусы актов, остатки по договору. Мы предложили организовать интеграцию между АУД и КЦ для того, чтобы по API передать в КЦ информацию об объемах и стоимости факта выполнения по договору, а также об объеме и стоимости с НДС остатка по договору. На стороне КЦ реализовали асинхронное API — запросы складывали в табличку, затем в несколько потоков разбирали данные и генерировали две сметы на основании данных запросов. 

Итоговая реализация

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

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

В результате за месяц с ресурсом из двух аналитиков и двух разработчиков мы завершили доработки в двух системах (КЦ и АУД) и автоматизированно перенесли на новую ставку порядка 136 тысяч договоров. В ходе обработки возникли ошибки, но в незначительном количестве — порядка 200 договоров сломались, из них вручную удалось починить около 150. Примерно 50 договоров не удалось провести, и они ушли на альтернативный процесс, в котором все согласование смет и подача актов осуществляются без автоматизированного контроля.

Какие качества аналитика повышают его востребованность в 2026 году?

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

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

1. Инициативность

Если аналитик видит риск или возможность, не нужно ждать, пока бизнес сам это увидит и оформит в задачу. Ценность в том, чтобы принести проблему раньше и помочь сформулировать решение.

2. Знание продукта и бизнес-контекста

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

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

3. Способность строить доверительные коммуникации с бизнесом 

Бизнес не готов слушать «первого вошедшего в дверь». Выстраивание доверительных отношений — это долгий процесс. Коллеги должны быть уверены в ваших компетенциях на опыте решения предыдущих задач и считать вас не просто усложняющим принятие решений коллегой, а партнером, который поможет создать ценность.

4. Способность брать на себя ответственность за результат 

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

5. Умение экономить время на рутине, используя ИИ

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

6. Умение внедрять изменения в процессах, а не информационные системы

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

Вывод

Современные реалии диктуют новые правила. Если команда ИТ и аналитиков хочет, чтобы бизнес видел в них не статью расходов, необходимо вкладывать ресурсы в выстраивание долгосрочных и партнёрских отношений. Это важно, чтобы в эпоху, когда про любое направление появляются мысли “а не оптимизировать ли нам это и заменить на ИИ?”, каждая сторона понимала важность друг друга.

 Закончить хотелось бы в духе сборника лучших цитат ВК: «Если после вас остается только ТЗ, вы сделали работу. Если меняется бизнес — вы создали ценность».