ИИ-Напарник работает как персональный агент конкретного сотрудника. У каждого менеджера свой Напарник, и он живёт в том же мессенджере, где менеджер уже общается с коллегами и поставщиками. Напарник знает приоритеты и историю решений своего человека, имеет доступ к корпоративным данным и системам в рамках его прав, координирует функциональных агентов и видит следующий шаг.
С точки зрения сотрудника всё проще, чем звучит. У него появляется один собеседник, к которому можно прийти со словами «почему упала молочка в регионе Х» или «подготовь к завтрашней встрече по KPI категории», и в ответ получить готовый разбор с рекомендацией. Под капотом для этого может задействоваться несколько разных агентов и систем, но менеджеру это знать не обязательно.
ИИ-Напарник работает как персональный ИИ-агент сотрудника. У Напарника есть три свойства, и важны они все вместе. Если убрать любое, остаётся либо чат-бот, либо copilot внутри одного приложения, либо функциональный агент из третьей эпохи.
Персональность
Напарник закреплён за конкретным сотрудником. Он знает его роль, портфель ответственности, KPI, активные переговоры, стиль коммуникации и историю решений. При этом Напарник менеджера A не имеет доступа к данным менеджера B, кроме случаев явной коммуникации между сотрудниками.
Единая точка входа
Один интерфейс ко всей корпоративной среде. Сотрудник уже не выбирает, к какой системе или агенту обратиться. Он формулирует задачу обычным языком, а Напарник сам определяет, кого подключить и в каком порядке.
Партнёрская позиция
Вместе с ответом Напарник предлагает следующий шаг и критический анализ. У него нет своей повестки внутри компании, поэтому он может прямо сказать «здесь цифры не сходятся» или «в прошлый раз похожее решение просадило маржу».
Здесь же видна разница с ассистентами внутри отдельных приложений. Copilot в BI помогает работать с BI, copilot в почте помогает с почтой, а Напарник работает с ситуацией сотрудника целиком и обращается к корпоративным системам как к инструментам под конкретную задачу.
Категорийный менеджер обычно держит в голове карту систем. Ему приходится помнить, где лежат продажи и остатки, где ведутся промо и переговоры, в какой системе хранятся регламенты, а где висят задачи. Часть из этих систем дублирует друг друга, часть конфликтует, часть периодически ломается. Само переключение между ними занимает заметную часть рабочего времени, и менеджер регулярно теряет контекст. Ситуация знакомая. Зашёл в один отчёт за цифрой, отвлёкся на письмо, к цифре уже не вернулся, потому что письмо породило ещё три задачи.
Напарник убирает эту карту из головы сотрудника. Например, менеджер пишет в мессенджер «дай продажи по молочке за март по регионам» и тут же получает ответ. За этим ответом могут стоять Text2SQL-агент, обращение к DWH, проверка через агента базы знаний, но всё это происходит на стороне Напарника. Точно так же менеджер спрашивает «что у нас по поставщику X», «есть ли свободный час с Ивановым на четверг», «найди регламент по делистингу». То есть везде остаётся один и тот же канал и обычный язык.
Базовый канал коммуникации устроен как корпоративный мессенджер с мобильной и десктопной версиями. Веб-интерфейс и дашборды появляются позже, под конкретные сценарии. Голосовой ассистент на переговорах остаётся отдельной историей, она описана в открытых вопросах 04-usecases.
Часть полезной работы Напарник делает сам, без запроса. Это возможно, потому что у него есть расписание сотрудника, понимание его приоритетов и доступ к потокам данных. Утром он готовит брифинг, перед встречей собирает досье, по сработавшему алерту приносит готовый разбор, а коллеге сам напоминает про обещанный к среде расчёт. Как устроен этот проактивный цикл на уровне платформы, разобрано в 05-architecture, раздел «Проактивный цикл».
Проактивность сотрудник обязательно настраивает под себя. Менеджер задаёт пороги чувствительности (например, «не дёргай, если отклонение меньше 5%») и определяет приоритеты по категориям, поставщикам, SKU. Если этого не сделать, Напарник довольно быстро превращается в источник шума, и им перестают пользоваться.
Менеджер делает свою работу как раньше, а Напарник параллельно с ним делает то, что иначе пришлось бы держать в голове или откладывать на потом.
До прихода менеджера, к 9:00. Утром в чате уже лежит брифинг с приоритетными задачами дня. По двум критичным поставкам Напарник за ночь сам написал логистам и собрал у них предварительные ответы. Менеджер видит сводку и сразу понимает, чем заниматься первым, без обхода десятка систем.
Около 10:30 в одной из категорий случается резкий провал по конкретным SKU. Напарник не пересылает менеджеру голый алерт. Он сам прогоняет первичный разбор, отвергает очевидные гипотезы и приходит с диагностикой и тремя вариантами действий. Менеджер выбирает один, остальное Напарник доводит сам.
За час до встречи, к 13:00. В календаре стоят переговоры с поставщиком в 14:00. Никто Напарника не дёргает, но он сам видит встречу и заранее готовит досье. Туда попадают индексы цен, история уступок, статусы SLA и доля SKU в категории. К менеджеру досье приходит до того, как тот успевает его попросить.
В течение дня Напарник контролирует договорённости: на прошлой неделе коллега из соседнего отдела обещал расчёт к среде. Сегодня среда. Напарник сам напоминает Напарнику коллеги, получает обновлённый срок и приносит менеджеру результат. Менеджеру не пришлось превращаться в контролёра.
После окончания рабочего дня менеджер ушёл, а Напарник продолжает мониторить метрики и события. Если случается срыв доставки или жалоба от партнёра, Напарник классифицирует событие по согласованным правилам. Срочное уведомление уходит менеджеру в мессенджер сразу же. Менее срочное копится в утренний брифинг следующего дня.
Здесь видна проактивная половина работы. Реактивная половина (то есть случаи, когда менеджер сам приходит с вопросом или поручением), описана ниже в разделе «Как выглядит диалог с Напарником».
Выше в разделе «Рабочий день» показано, что Напарник делает сам. Дальше четыре коротких диалога. Они показывают вторую половину работы, ту, где менеджер сам приходит к Напарнику с вопросом или поручением. Это не сценарии бизнес-использования, они полностью разворачиваются в 04-usecases. Здесь интересна форма реплик.
Аналитический запрос
Менеджер.«Почему упала молочка в Сибири за март?»
Напарник.«Главная причина в росте закупочных цен Danone на 8% и недопоставках трёх SKU из-за SLA 91% при норме 95%. Совокупный эффект на категорию -9,2%. Доказательная база и отвергнутые гипотезы лежат в карточке ниже. Через три дня встреча с Danone, могу подготовить досье».
Менеджер.«Подготовь. И добавь в разбор демпинг конкурента, мы это видели в марте».
Напарник.«Принял. Учту в следующих похожих разборах».
Подготовка к переговорам
Менеджер.«Saverio просит +5% к закупочной цене, встреча завтра в 14:00».
Напарник.«Готовлю досье. Аргументы против повышения такие. Индекс цен на сырьё -3% за квартал, недопоставки 17 млн ₽ из-за SLA 87% при норме 95%, на встрече в сентябре поставщик уступил при угрозе делистинга, доля SKU в категории 34%. Рекомендую начать с SLA, это самая сильная позиция. Слайды нужны?»
Сборка статусов по поручению
Менеджер.«Собери у маркетинга и логистики статусы по летнему промо».
Напарник.«Отправил запросы Напарникам Петровой и Иванова. Жду ответы, обычно собирается за 20–40 минут. Пришлю сводку, как только всё валидируют».
Через 35 минут.
Напарник.«Сводка готова. По двум промо из четырёх есть отставание от плана с указанием причин. Отдельно отметил, что у Иванова открытый вопрос по бюджету, ждёт твоего решения».
Встреча с коллегой
Менеджер.«Поставь встречу с Петровой на этой неделе на 30 минут, обсудить промо в кондитерке».
Напарник.«Договорился с её Напарником. Свободный слот пришёлся на четверг 11:30. Поставил, повестку добавил. К началу встречи пришлю короткий бриф, в нём будет, что у Петровой по этой категории сейчас и какие открытые вопросы остались с прошлого раза».
В реальном разговоре будет больше уточнений, поправок и переключений, здесь это убрано для краткости. Зато хорошо видна форма реплики. Везде всё тот же единый канал из раздела «ИИ-Напарник как единое окно», а в ответ приходит разбор вместе с предложением следующего шага.
Напарник полезен ровно в той мере, в какой он понимает контекст конкретного сотрудника. Подробное устройство памяти и состав каждого слоя описаны в 05-architecture, раздел «Память и контекст». Здесь интересно только то, что из этого видит сам сотрудник.
Контекст растёт со временем. Чем дольше Напарник работает с менеджером, тем точнее он попадает в его задачи. Он запоминает, как сотрудник формулирует поручения, какой длины ответы любит, какие аргументы у него обычно срабатывают на переговорах, как он реагировал в похожих ситуациях раньше. За счёт этого «Напарник, которого включили вчера» сильно отличается от «Напарника, который работает с менеджером полгода». Это свойство сотрудник замечает в работе сам.
Напарник также ведёт профили контрагентов и коллег, с которыми работает менеджер. Здесь профиль одного и того же поставщика у разных менеджеров будет разным, потому что они наблюдают его в своих переговорах. Архитектурное устройство профилей и правила обмена ими между Напарниками описаны в 05-architecture, раздел «Профили контрагентов».
Часть персонализации сотрудник задаёт сам через скиллы. Это короткие декларативные инструкции о том, как Напарник должен работать с этим человеком. Несколько типичных формулировок.
«Отчёты собирай в формате с разрезом до и после промо».
«По поставщикам категории X сразу добавляй долю SKU в категории».
«При отклонениях меньше 5% не дёргай».
«При подготовке к комитету сразу добавляй разрез по конкуренту».
Скиллы отличаются от того, что Напарник запоминает сам, тем, что в них живут правила, а не накопленная история решений. Сотрудник может добавить, отключить или поправить скилл в любой момент. Платформенный механизм скиллов разобран в 05-architecture, раздел «Скиллы».
Сам Напарник как правило не делает факторный анализ, не пишет SQL и не ищет по регламентам. Эту работу он делегирует специализированным функциональным агентам. Примеры таких агентов в 03-agents, раздел «Классификация функциональных агентов», а здесь интересно, как Напарник ими управляет.
Типовой цикл выглядит примерно так.
Сотрудник формулирует ситуацию обычным языком, например «почему упала молочка в Сибири».
Напарник распознаёт класс ситуации и собирает план разбора. В простом случае хватит одного агента, в сложном понадобится два-три, работающих параллельно. План остаётся внутренним, сотрудник его не видит, если сам не попросит показать.
Напарник делегирует задачи функциональным агентам. Каждому уходит конкретная задача с параметрами, например период, регион, категория, набор гипотез. Агенты работают либо независимо и параллельно, либо последовательно, в зависимости от поставленного плана.
Напарник собирает результаты в единый ответ. Это синтез, с главным выводом, доказательной базой, отвергнутыми гипотезами и предлагаемым следующим шагом, а не простая склейка трёх отчётов через слово «также».
Сотрудник получает результат вместе с предложением действия. Если он валидирует вывод или поправляет его, Напарник запоминает поправку и в следующий раз учтёт её в похожей ситуации.
Сложные ситуации обычно требуют нескольких таких циклов. Менеджер может уточнить, Напарник в свою очередь дозапрашивает агентов и возвращает уточнённый разбор. Всё это происходит в одном диалоге в одном чате, без переключения интерфейсов.
Ещё одно важное свойство в том, что добавление нового функционального агента не увеличивает когнитивную нагрузку на сотрудника. Появился агент по эластичности цен, и у Напарника становится на одну возможность больше, а интерфейс остаётся прежним.
Опыт сотрудника не должен исчезать вместе с его уходом из компании. И опыт сильного сотрудника не должен оставаться внутри одной головы, пока коллеги в соседнем отделе изобретают то же самое заново. Для этого нужна организационная память. Это многослойное хранилище контекста и опыта, к которому у Напарника есть доступ. Полное устройство памяти, состав слоёв, правила доступа и политики хранения описаны в 05-architecture, раздел «Память и контекст».
С точки зрения сотрудника организационная память даёт два пользовательских эффекта.
Первый эффект состоит в преемственности. Когда сильный менеджер уходит, его личная память не передаётся новому сотруднику автоматически. Это было бы странно и небезопасно. Передаётся то, что уже стало паттерном, а именно проверенные подходы, типовые аргументы, разборы кейсов. Преемник получает их с первого дня и не восстанавливает по обрывкам файлов и устным рассказам. Механизм отбора и валидации паттернов лежит в 05-architecture, раздел «Коллективная память».
Второй эффект состоит в доступе к чужим удачным решениям внутри своей роли. Если в категории кондитерки кто-то нашёл рабочий аргумент против повышения закупочной цены, после валидации куратором этот аргумент становится доступен Напарникам остальных категорийных менеджеров. Сотруднику не нужно знать, как это технически устроено. Достаточно того, что Напарник учитывает удачные практики коллег при подготовке его собственных решений.
Напарник не вводится одним релизом. Он растёт по уровням, и каждый следующий уровень опирается на зрелость предыдущего, на работающие интеграции, накопленную обратную связь и выстроенные правила безопасности. Эту лестницу удобно использовать на пресейле, чтобы договориться с заказчиком об ожиданиях от пилота и обозначить, куда внедрение движется дальше.
| Уровень | Что Напарник делает | Что становится возможно |
|---|---|---|
| 1. Операционный помощник | Рутина по почте, календарю, голосу, транскриптам, поиску по корпоративным источникам. | Освобождается до 30–40% рабочего времени сотрудника от механической работы. |
| 2. Аналитический помощник | Доступ к данным и BI, факторный анализ отклонений, нестандартные срезы через Text2SQL, подготовка разборов и презентаций, проактивный мониторинг аномалий. | Время от вопроса до обоснованного ответа сжимается на порядок, а часть проблем ловится ещё до того, как менеджер открыл отчёт. |
| 3. Коммуникационный помощник | Профили контактов, симулятор коммуникаций, подсказки на встречах в реальном времени (тот самый голосовой ассистент, 04-usecases), второе мнение перед решением. | P&L-эффект на переговорах и заметный рост качества внутренних коммуникаций. |
| 4. Мультиагентный координатор | Общение Напарников между собой, горизонтальный обмен паттернами, вертикальная агрегация. | Корпоративная среда работает как сеть взаимодействующих агентов. Преемственность экспертизы. |
Базовый слой. Напарник снимает рутину, которая в крупной сети съедает значительную часть дня. Агент умеет сортировать входящую почту по срочности и теме, эскалировать критичные сигналы от поставщиков, подбирать время для встреч с учётом календарей и предпочтений сотрудника. Напарник расшифровывает голосовые сообщения менеджера в текст и превращает их в действия — письмо, задачу, поиск. Из транскриптов совещаний Напарник вытаскивает договорённости и дедлайны, а на вопросы вида «где найти регламент Y» или «по какому шаблону подавать заявку X» отвечает по корпоративным источникам.
Видимый эффект на этом уровне обычно появляется раньше всего, поэтому он хорошо подходит на первые недели пилота. Метрики тоже простые. Замеряем время на типовую операцию до и после, количество писем, обработанных без участия сотрудника, и долю встреч с автоматически сформированной повесткой.
Напарник получает доступ к данным и начинает отвечать на содержательные вопросы по категории. Сотрудник спрашивает обычным языком, почему упала молочка в регионе, а в ответ приходит факторный разбор с главным выводом, доказательной базой и отвергнутыми гипотезами. Под капотом работают функциональные агенты, которые ходят в хранилище и BI, делают нестандартные срезы через Text2SQL, считают эффект промо и готовят черновики разборов и презентаций. Часть этой работы Напарник делает без запроса, потому что в фоновом режиме ловит аномалию раньше, чем она доходит до планёрки.
Эффект на этом уровне виден на скорости и качестве решений. Время от вопроса до обоснованного ответа падает с дней до минут, а у менеджера на руках сразу расширенная картина, а не та, до которой он успел докопаться руками. Здесь смотрят на время до первичного разбора, долю разборов, к которым менеджер вернулся за уточнениями, и оценку точности диагностик по 5-балльной шкале.
Напарник начинает работать с людьми вокруг сотрудника. Он ведёт профили контактов в личной памяти, и в этих профилях лежат поставщики, коллеги из смежных подразделений и руководители. В профиле фиксируется стиль аргументации, чувствительные темы, прецеденты успеха и неудач, типичные триггеры уступок. Перед значимой коммуникацией Напарник работает как симулятор и предупреждает, например, что коммерческий директор спросит про каннибализацию, у тебя нет этого раздела.
Эффект на этом уровне уже прямой, P&L-метрики начинают двигаться. Лучше подготовленные переговоры дают доли процента бэк-маржи, и на масштабе крупной сети это десятки миллионов рублей в год. Здесь смотрят на долю встреч с подготовленным досье, эффект на маржу категорий и количество итераций при согласовании внутренних документов.
Напарники разных сотрудников начинают разговаривать между собой по управляемой политике межагентского взаимодействия. Например, менеджер просит своего Напарника собрать статусы по промо у коллег. Напарники коллег идут к своим сотрудникам, собирают данные, валидируют и возвращают ответ. Между подразделениями появляется аудируемый поток запросов, и он сам по себе становится данными о том, как работает организация.
На этом уровне начинает работать горизонтальный обмен паттернами. Удачный подход одного менеджера после валидации куратором становится доступен Напарникам всей команды. Так коллективная память переходит из описания в реальный рабочий механизм. Уровень 4 не включается рывком, он добавляется поверх первых трёх и требует отдельной проработки правил.
Напарник и функциональный агент относятся к разным сущностям, и на словах их легко перепутать.
| Критерий | ИИ-Напарник | Функциональный агент |
|---|---|---|
| За кем закреплён | За конкретным сотрудником | За классом задач |
| Сколько в системе | По одному на сотрудника | Один общий, используется всеми Напарниками |
| Как вызывается | Сотрудник пишет в обычный мессенджер | Вызывается Напарником, не сотрудником |
| Что знает | Контекст и историю своего человека | Свою предметную область и инструменты |
| Что возвращает | Результат с рекомендацией следующего шага | Структурированный ответ по своей задаче |
| Доступ к данным | Через права своего сотрудника | По узкой инструментальной политике |
| Видим ли сотруднику | Да, постоянный собеседник | Обычно нет, работает «под капотом» |
В обычный рабочий день сотрудник может вообще ни разу не вызвать функционального агента напрямую. Все обращения идут через Напарника, и так получается удобнее. Но при необходимости менеджер может работать с конкретным функциональным агентом сам. Примеры функциональных агентов в 03-agents.
Напарник работает как компетентный партнёр, но самостоятельность у него ограничена. На критичных решениях он сотрудника не подменяет и в обход корпоративных правил не действует.
Границу автономии задаёт Tier-модель. Она разделяет действия по уровню эффекта и обратимости. Например, чтение данных и подготовка черновиков разрешены по умолчанию. А действия с внешним эффектом (отправка письма, изменение в учётной системе, бронирование встречи) требуют явного подтверждения сотрудника. Автономные действия по расписанию или триггеру включаются точечно по согласованным правилам, после периода доверия и согласования с ИБ. Конкретный состав уровней, классификация действий и механизм подтверждения описаны в 05-architecture, раздел «Tier-модель автономии».
Помимо Tier-модели у Напарника есть несколько ограничений по содержанию работы.
С цифрами Напарник работает как передатчик, а не источник истины. Любая цифра, которую он показывает, ссылается на источник в корпоративном хранилище (таблицу, период, набор фильтров). Сотрудник может в один клик провалиться в источник и проверить.
В обход прав сотрудника Напарник тоже не работает. Если у менеджера нет доступа к данным соседнего подразделения, Напарник этих данных тоже не получит. Подробности лежат в 05-architecture, раздел «Безопасность и права доступа».
Метрики удобно разносить на операционные, бизнес-метрики и пользовательские. Нужны все три. По одним бизнес-метрикам картина пилота выходит неполной, а на одних операционных не выйдет разговор с коммерческим директором.
| Уровень | Метрика | Как измеряется |
|---|---|---|
| Операционный | Время на типовой аналитический запрос | Замер до и после на одинаковом наборе вопросов |
| Операционный | Доля встреч с подготовленным досье | Отметка в календаре или подтверждение от менеджера |
| Операционный | Время от аномалии до алерта | Лог появления отклонения и времени уведомления |
| Бизнес | Эффект на маржу категории | Сравнение когорт менеджеров с Напарником и без |
| Бизнес | Дополнительная бэк-маржа в переговорах | Отдельная отметка по подготовленным переговорам |
| Бизнес | Время адаптации нового менеджера | До выхода на целевой KPI категории |
| Пользовательский | NPS менеджеров | Регулярный замер 1–2 раза в месяц |
| Пользовательский | Доля задач, в которых менеджер обращается к Напарнику | Лог обращений / общий объём типовых задач |
| Пользовательский | Качество диагностик | Оценка менеджера по 5-балльной шкале на каждом разборе |
Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.