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