Сценарии использования

Документ описывает работу платформы через реальные ситуации торговой сети. Внутри каждого сценария разобрано, что менеджер делает сегодня, что меняется с появлением Напарника, какие функциональные агенты подключаются и какой эффект ожидается. Это основной материал для бизнес-питча, демо и обсуждения пилота. Пользовательская модель Напарника описана в 02-partner, каталог агентов лежит в 03-agents, архитектура разобрана в 05-architecture, а этапы внедрения собраны в 07-roadmap.

Коротко

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

Сценарии написаны от имени бизнеса, а не от имени платформы. То есть не «агент факторного анализа делает декомпозицию», а «менеджер за пять минут получает разбор, с которым можно идти к коммерческому директору». Технические детали (какие агенты под капотом, какие данные, какая оркестрация) приведены в каждом сценарии, но они не главные. В каждом сценарии важно показать сдвиг в работе человека.

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

Принципы описания сценариев

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

Язык бизнеса, а не платформы

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

Сравнение с текущим процессом

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

Ясная граница между Напарником и человеком

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

Реалистичные эффекты

Лучше осторожная цифра с пояснением «зависит от стартовой зрелости заказчика», чем ровные 30% к марже на каждом слайде. Эффекты, которые звучат красиво, но плохо измеряются, лучше выносить отдельно как качественные.

Ключевые пользовательские роли

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

Категорийный менеджер

главный герой

На категорийном менеджере висит P&L категории целиком, от переговоров с поставщиками и ассортиментной матрицы до полки, оборота, маржи и промо. Большинство сценариев в этом документе описаны именно от его лица, потому что у него больше всего ситуаций, в которых Напарник даёт быстро видимую ценность.

Руководитель направления

Руководитель направления координирует нескольких категорийных менеджеров и смотрит на портфель целиком, и потому ему регулярно нужна кросс-категорийная картина для коммерческой дирекции. Это как раз то место, где особенно сильно работает межнапарниковая агрегация. У него на руках сводка собирается из ответов Напарников его категорийщиков, а не из «соберите мне отчёт к понедельнику».

Логист и операционный руководитель

На стороне логистики и операций сидят данные, без которых не работают сценарии OOS и переговоров с поставщиками. Сюда относятся SLA, переключение между РЦ, фактические даты прихода. В обоих сценариях Напарник логиста работает в паре с Напарником категорийщика, и большая часть переписки между ними происходит без участия людей.

Прайс-менеджер и руководитель промо

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

Коммерческий директор

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

Карта сценариев

Полная карта сценариев нужна, чтобы видеть общую картину и понимать, где какие агенты задействованы. Подробно разобраны первые четыре. Пятый (межфункциональная встреча) уже достаточно проработан, чтобы стоять рядом с основными. Остальные оставлены в backlog.

Сценарий	Главный пользователь	Ключевые агенты	Статус описания
Подготовка к переговорам с поставщиком	Категорийный менеджер	Переговоры, финансовый эффект, OOS, базы знаний	детально
Разбор падения продаж по категории	Категорийный менеджер	Факторный анализ, Text2SQL, OOS, промо	детально
Анализ эффективности промо	Руководитель промо, категорийный менеджер	Промо, финансовый эффект, конкурентный мониторинг	детально
Управление OOS и доступностью товара	Категорийный менеджер, логист	OOS, прогнозирование, переговоры	детально
Межфункциональная встреча через Напарников	Любой сотрудник со встречами	Встреч и follow-up, базы знаний	детально
День категорийного менеджера с Напарником	Категорийный менеджер	Все приоритетные	backlog
Подготовка к ассортиментному комитету	Категорийный менеджер, директор по категориям	Ассортимент, финансовый эффект, конкурентный мониторинг	backlog
Кризисная ситуация (срыв поставки)	Логист, категорийный менеджер	Алерты, OOS, переговоры, встреч и follow-up	backlog
Онбординг нового менеджера	Новый сотрудник	Базы знаний, организационная память	backlog
Подготовка управленческого summary	Руководитель направления, директор	Все, через Напарника	backlog
Поиск и распространение лучших практик	Команда, куратор	Организационная память	backlog

Шаблон описания сценария

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

Бизнес-ситуация. Конкретная история, в которой оказался сотрудник. Описывается, что произошло, в каком контексте и к какому сроку нужно отреагировать. Желательно с реалистичным сюжетом, а не с «менеджеру нужно подготовить отчёт».
Участники. Кто из людей вовлечён, какая роль у каждого. Сюда же попадают внешние участники, например поставщик.
Текущий процесс. Как ситуация разбирается сегодня, без платформы. По возможности с реальными временами и количеством переключений между системами.
Боли текущего процесса. Что именно болит. Не «процесс несовершенен», а конкретные потери. Сюда относятся потерянное время, упущенные аргументы, неиспользованная фактура, забытые договорённости.
Как процесс выглядит с Напарником. Тот же сюжет в новой модели работы. Описываются шаги диалога, что делает Напарник сам, и где останавливается, чтобы получить явное подтверждение от человека.
Какие функциональные агенты участвуют. Список агентов, которые подключаются, и за что отвечает каждый. Подробности реализации сюда не пишем, они лежат в 03-agents.
Какие данные используются. Источники, к которым обращается платформа. Сюда обычно входят хранилище, BI, регламенты, почта, календарь, внешние индексы и так далее.
Какие решения принимаются. Что именно меняется в рабочем дне сотрудника по итогам сценария. Описывается само действие и форма, в которой оно фиксируется (письмо, задача в трекере, документ на согласование).
Где нужен human-in-the-loop. Точки, в которых Напарник останавливается и ждёт явного подтверждения. Это разные точки в зависимости от Tier-модели.
Ожидаемый бизнес-эффект. Качественный и, по возможности, количественный. Лучше указать диапазон с оговорками, чем красивую среднюю.
Метрики успеха. Как мы поймём, что сценарий действительно работает в пилоте.

Сценарий 1. Подготовка к переговорам с поставщиком

Бизнес-ситуация

Поставщик Saverio (молочная продукция) присылает письмо. С первого числа следующего месяца он хочет повысить закупочную цену на 5%, ссылается на рост себестоимости. Встреча по этому поводу в среду, у Алексея Ивановича, категорийного менеджера направления «Молочные продукты», есть полтора рабочих дня на подготовку. Решение нетривиальное. Saverio занимает 34% полки в категории, его SKU давно знакомы покупателю, прямая замена быстро не находится. Согласие на +5% означает потерю бэк-маржи примерно на 18 миллионов рублей в год. Отказ означает риск ухудшения SLA, который и без того в зоне неопределённости.

Участники

Переговоры ведёт категорийный менеджер. По данным он опирается на логиста направления (фактические поставки и SLA) и прайс-менеджера (ценовое позиционирование категории). Финальное решение по уровню компромисса подписывает коммерческий директор. На той стороне стола сидит менеджер по работе с сетями со стороны Saverio.

Текущий процесс

Сегодня подготовка к такой встрече занимает у менеджера от полудня до целого дня и часто остаётся неполной.

Менеджер вытаскивает из BI продажи по SKU Saverio за последние 6–12 месяцев, отдельно по регионам, отдельно по магазинам. Несколько часов на сборку, скриншоты, сведение в Excel.
Запрашивает у логистов данные по fill rate и недопоставкам. Логисты обещают вернуться завтра, потому что у них свой загруз и свой формат отчётов. Часть данных приходит в почте в виде Excel-вложения.
Идёт в почту искать, что у нас с Saverio было в прошлый раз. Когда повышал цену, на чём согласились, какие были аргументы. Часть переписки потеряна или переведена в архив. По историческим данным можно восстановить только последний раунд.
Звонит коллеге, который раньше вёл этого поставщика. Узнаёт, что у Saverio есть слабое место, а именно недавняя жалоба на упаковку из соседней сети. Записывает в блокнот.
Открывает аналитический Telegram-канал, где обычно постят индексы цен на сырое молоко. Видит, что индекс снизился на 3% за квартал. Делает скриншот.
Собирает аргументационный пакет в Word, частью пересказом, частью копипастой. Отдаёт коммерческому директору на ревью. Тот просит добавить разбор по доле SKU в категории, потому что без него непонятен рычаг давления. Цикл идёт ещё полчаса.
К моменту встречи менеджер чувствует, что готов «процентов на семьдесят». Какой-то части аргументов не успел собрать, какую-то забыл вытащить из системы.

Боли текущего процесса

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

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

Как процесс выглядит с Напарником

С платформой подготовка идёт по другому маршруту. Письмо от Saverio Напарник заметил сразу. Оно классифицировано как переговорное и подсвечено как требующее внимания.

Утро понедельника. В мессенджере менеджер видит сообщение от Напарника. «Saverio запросил +5% к закупочной цене. Встреча у тебя в среду в 14:00 (поставил предварительно). Готовлю досье. По сильным сторонам нашей позиции у нас индекс цен на сырое молоко -3% за квартал, недопоставки 17 млн ₽ из-за SLA 87% при норме 95%, в сентябре поставщик уже уступал при угрозе делистинга. По слабым сторонам у нас доля SKU в категории 34%, прямой замены без потерь нет. Подготовлю полный пакет к 12:00, согласовать со встречей коммерческому директору?».
К полудню понедельника менеджер получает структурированный документ. Внутри лежит разбор продаж по SKU и регионам, анализ маржинальности, разбор SLA с разбивкой по месяцам, индексы цен на сырьё, прецеденты переговоров (2024, 2025), профиль контактного лица со стороны Saverio (что важно, какие аргументы работали, на что эмоционально реагирует) и оценка финансового эффекта решения «согласиться» против «не согласиться» и против промежуточных вариантов.
Менеджер правит. Уточняет, чтобы Напарник добавил разбор по двум SKU, по которым недавно меняли поставщика, чтобы было видно, что замена возможна. Напарник за минуту дописывает раздел.
Тот же день, 14:00. Менеджер делится черновиком с коллегами через Напарника. Напарник прайс-менеджера и Напарник логиста добавляют свои комментарии. Это занимает у людей на той стороне минуты, потому что фактура уже подготовлена.
Среда, 13:50. Перед встречей Напарник присылает сжатую карточку на одну страницу. На ней три ключевых аргумента, один финансовый расклад и одна точка отступления.
Среда, 14:00. Встреча идёт онлайн. Поставщик ссылается на рост стоимости упаковки. Напарник в реальном времени подсказывает в боковой канал, что индекс цен на гофрокартон -2% за квартал, а упаковка в структуре себестоимости поставщика около 8%. Менеджер встраивает это в разговор без видимой паузы. Поставщик уходит на аргумент про логистику. Напарник подсказывает SLA по последним трём месяцам и фактический fill rate 87%. Разговор заканчивается компромиссом. Повышение идёт на 1.5% при условии возвращения SLA к 95%, условие фиксируется в дополнительном соглашении.
Среда, 15:30. После встречи Напарник сам делает следующий шаг. Записывает договорённость в личную память, обновляет профиль контактного лица Saverio, ставит задачу логисту начать мониторинг fill rate под новое условие, готовит черновик письма-подтверждения от менеджера. Менеджер читает, нажимает «отправить». Напарник кладёт договорённость в коллективную память как кандидата для будущих переговоров. Это успешный паттерн «повышение в обмен на восстановление SLA» с пометкой «нужна валидация куратора перед публикацией».

Какие функциональные агенты участвуют

Главную работу делает агент переговоров. Он собирает досье, профилирует контактное лицо поставщика и формирует аргументационный пакет. Параллельно с ним моделирует варианты решения агент финансового эффекта (что будет с маржой при каждом сценарии), агент OOS приносит фактуру по SLA и недопоставкам, а агент базы знаний достаёт прецеденты прошлых переговоров. На обвязке встречи (календарь, слот, постановка задач после) работает агент встреч и follow-up. Подробное устройство всех этих агентов лежит в 03-agents, разделе «Карточки приоритетных агентов».

Какие данные используются

В дело идут продажи, маржа и доля поставщика в категории из корпоративного хранилища, данные WMS и SLA (fill rate, недопоставки, штрафы), внешние индексы цен на сырьё и упаковку. Дополняют картину прецеденты прошлых уступок и стандарты переговоров из корпоративной базы знаний и история переписки с поставщиком из почты. Профиль контактного лица берётся из личной памяти Напарника, а слоты под встречу и follow-up живут в календаре и таск-трекере.

Какие решения принимаются

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

Где нужен human-in-the-loop

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

Ожидаемый бизнес-эффект

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

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

Метрики успеха

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

Сценарий 2. Разбор падения продаж по категории

Бизнес-ситуация

Понедельник, утренний ритуал. Категорийный менеджер открывает BI и видит цифру «Молочные продукты, Сибирский ФО, март, факт −9.2% к плану». Через неделю состоится еженедельная коммерческая планёрка, на которой нужно объяснить, что произошло, и сказать, что с этим делать. На уровне категории по сети в целом цифра в норме, провал именно в одном регионе.

Участники

Разбор ведёт категорийный менеджер, и с этим разбором он идёт на планёрку. До платформы такие запросы обычно делегировались аналитику коммерческой дирекции, поэтому он остаётся в сценарии как «человек, которого мы освобождаем». Логист направления держит фактические данные по поставкам в Сибирский ФО, региональный коммерческий руководитель сидит в этом регионе как стейкхолдер вопроса, а коммерческий директор задаёт вопросы на планёрке.

Текущий процесс

Сегодня разбор идёт в несколько итераций и редко укладывается в один день.

Менеджер видит цифру и формулирует первую гипотезу, что это, вероятно, OOS. Идёт в BI смотреть остатки. Видит, что по нескольким SKU остатки действительно были низкие, но это не объясняет всего минуса.
Запрашивает у аналитика факторный разбор. Аналитик стоит в очереди, разбор будет «к среде, может, к четвергу».
К среде разбор приходит в виде диаграммы каскада. Главный вклад дают рост закупочных цен Danone +8% и недопоставки трёх SKU. Менеджер хочет провалиться в детали, но в Excel это сделать сложно. Там готовый отчёт, без возможности перекроить разрез.
Идёт к логистам. Те подтверждают недопоставки, обещают прислать таблицу к концу дня. Таблица приходит в формате, не совместимом с тем, что у менеджера в Excel.
К пятнице картина вроде сложилась. Менеджер собирает презентацию. На планёрке коммерческий директор спрашивает, сравнивали ли с конкурентом. Сравнить времени уже не было.
После планёрки менеджер ставит себе задачу на следующую неделю провалиться в данные конкурентов. Через неделю это снова не главный приоритет.

Боли текущего процесса

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

Дальше ломается глубина. Аналитик отдаёт готовый отчёт, в котором уже свёрнут разрез, и если на планёрке возникает новый вопрос (а он возникает почти всегда), ответа на него не будет до следующего цикла. Менеджер на планёрке отвечает «давайте проверим на следующей неделе», и эта «следующая неделя» означает реальный сдвиг решения в портфеле.

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

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

Как процесс выглядит с Напарником

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

Воскресенье ночью агент аномалий замечает значимое отклонение по молочной продукции в Сибири и запускает факторный разбор автоматически.
Утро понедельника, 9:15. В мессенджере у менеджера короткое сообщение от Напарника. «По молочке в Сибири за март -9.2%. Главная причина в росте закупочных цен Danone на 8% (вклад -5.4 п.п.) и недопоставках трёх SKU из-за SLA 87% (вклад -2.3 п.п.). Промо и конкуренты в норме. Доказательная база и отвергнутые гипотезы прикладываю. Через три дня встреча с Danone, готовить досье?».
Менеджер уточняет. «Покажи разрез по магазинам, есть подозрение, что в одной из подсетей подсильнее». Напарник за тридцать секунд возвращает разрез. Половина минуса концентрируется на 12 магазинах из 87. Эти магазины относятся к одному кластеру. По кластеру параллельно идёт ремонт холодильного оборудования.
Менеджер уточняет ещё раз. «Что было бы, если бы не было этой проблемы с холодильниками?». Напарник делает контрфактический расчёт. -9.2% превратились бы в -5.8%, и тогда основной фактор действительно цена Danone, а проблема холодильников добавляет 3.4 п.п. поверх.
Менеджер просит сравнение с конкурентом. Напарник вытаскивает доступные данные по доле полки и публичные индексы по категории. Делает оговорку, что по доступным данным на квартал у конкурента похожая динамика, но точную цифру по марту дать не может, потому что данные публикуются с задержкой.
Среда. На планёрке менеджер заходит с готовой картинкой. Главная причина, второй фактор, третий фактор, контрфактический расчёт, и в качестве рекомендации отдельный план по холодильникам и пересмотр условий с Danone в эту пятницу. Коммерческий директор спрашивает про конкурента, менеджер отвечает по существу. Спрашивает про промо, Напарник в боковом канале мгновенно подсказывает, что промо в марте по молочке в Сибири было два, ROI обоих в норме, каннибализации нет. Менеджер озвучивает.
После планёрки Напарник записывает выводы планёрки в личную память. Теперь, если через два месяца возникнет похожая ситуация, разбор начнётся не с пустого листа.

Какие функциональные агенты участвуют

Ядро сценария составляет агент факторного анализа. Он раскладывает отклонение на факторы и формирует диагностическую карточку с главным выводом, доказательной базой, отвергнутыми гипотезами и следующим шагом (эта структура карточки описана в 03-agents). Дополняют его несколько других агентов. Text2SQL делает нестандартные срезы по запросу менеджера, агент OOS приносит данные по SLA, а агент промо проверяет, не объясняется ли часть просадки промо-эффектом. Цепочка запускается с одного действия. Агент аномалий первым ловит отклонение и проактивно запускает разбор, не дожидаясь, пока менеджер откроет BI.

Какие данные используются

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

Какие решения принимаются

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

Где нужен human-in-the-loop

Сами разборы Напарник делает на Tier 1 (чтение и подготовка), и здесь явное подтверждение не требуется. Внешние действия по итогам разбора (постановка задач, запросы коллегам) уже идут через явный клик. Обновление коллективной памяти проходит через куратора, как в сценарии 1.

Ожидаемый бизнес-эффект

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

Параллельно меняется качество разбора. У менеджера на руках всегда расширенная картина (с конкурентом, промо, контрфактическим расчётом), а не та, до которой он успел добраться. На планёрке это видно сразу.

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

Метрики успеха

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

Сценарий 3. Анализ эффективности промо

Бизнес-ситуация

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

Это болезненная ситуация в индустрии. Внешние исследования говорят, что 59–72% трейд-промо в FMCG не окупаются, и эта оценка часто повторяется в консалтинговых отчётах разных лет. Реалистично ожидать, что и в этой кампании часть акций окажется в убытке. Открытым остаётся вопрос, какие именно и почему.

Участники

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

Текущий процесс

Руководитель промо запрашивает у аналитики разбор по кампании. Тот формирует Excel с продажами в промо, продажами до и после, скидкой, инвестицией и ROI. Берёт около недели.
Параллельно категорийный менеджер делает свой разбор. Что у него на полке, как менялась маржа, не было ли каннибализации между SKU. Это отдельный Excel.
Прайс-менеджер вносит свой кусок, а именно ценовое позиционирование и сравнение с конкурентом в период промо. Третий Excel.
Маркетинг присылает свой отчёт с охватами, медиа-миксом и эффективностью каналов. Четвёртый.
Кто-то (обычно руководитель промо) пытается всё это свести. Сводка получается крупными мазками. Общий ROI кампании, две-три иллюстрации. Детальный разбор по каждой акции с учётом каннибализации, эффекта на маржу категории и ценового позиционирования собрать не получается, не хватает времени.
На комитете доклад звучит как «общий ROI 12%, в целом успешно». Через месяц одна из акций оказывается в реальности в минусе по марже категории, потому что переключила покупателей с маржинального SKU на менее маржинальный. Это всплывает уже после, когда кто-то случайно посмотрел.

Боли текущего процесса

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

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

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

Как процесс выглядит с Напарником

В платформе разбор идёт сразу как сводный, и за каждым выводом закреплена цифровая фактура.

Понедельник. Напарник руководителя промо приносит сводный разбор летней кампании. «9 акций, 4 крупные. Чистый ROI с учётом каннибализации составляет +21% (две акции), +6% (две акции), -4% (одна акция), -12% (две акции). Главный фактор отрицательного ROI это каннибализация на собственный маржинальный SKU. Подробный разбор по каждой акции прикладываю».
В разборе по каждой акции есть единый блок. Цели, что фактически произошло, чистый эффект на категорию, разрез по каннибализации, разрез по маржинальности, влияние на ценовое позиционирование, медиа-вклад. Каждая цифра кликабельна, и можно провалиться к источнику.
Руководитель промо ставит вопрос. «А что было бы, если бы убрали из плана две убыточные акции и оставшийся бюджет перераспределили на три самые сильные?». Агент финансового эффекта пересчитывает за минуту, что прирост составит +9 п.п. к общему ROI кампании, при этом охват сокращается на 18%. Видна развилка не «делать ли промо вообще», а «как сбалансировать маржу и охват».
Категорийный менеджер кондитерки через своего Напарника подключается к разбору. Видит свою часть, добавляет комментарий, что акция №7 каннибализировалась на собственный новый бренд, который пытались разогнать, и на осень эту пару акций нужно разнести по времени.
Прайс-менеджер видит своими глазами, что одна из акций просадила воспринимаемый ценовой уровень на 8% за категорию в целом и эффект продержался ещё месяц после акции. Это раньше никто не считал, потому что лень.
Среда, комитет. Доклад идёт по сводной картинке. Что окупилось и почему, что не окупилось и почему, какой план на осень с учётом разбора. Решение состоит в том, чтобы отказаться от двух исторически слабых форматов, перебросить бюджет на три, плюс одна экспериментальная новая. Сравнение с прошлым годом идёт не по «общему ROI», а по реальному эффекту на маржу категории.
После комитета Напарник кладёт паттерн каннибализации между конкретной парой SKU в коллективную память. В следующий раз при планировании любой акции по этой паре Напарник предупредит автоматически.

Какие функциональные агенты участвуют

Главным здесь работает агент промо. Он считает чистый эффект акции с учётом каннибализации, эффекта на маржу категории и ценового позиционирования. Рядом с ним подключаются агент финансового эффекта (моделирует альтернативные сценарии вроде «убрать две убыточные акции и перераспределить бюджет») и агент конкурентного мониторинга, добавляющий внешний контекст по ценам и ассортименту конкурентов. Text2SQL даёт доступ к нестандартным срезам, а подготовку комитета берёт на себя агент встреч и follow-up.

Какие данные используются

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

Какие решения принимаются

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

Где нужен human-in-the-loop

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

Ожидаемый бизнес-эффект

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

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

Метрики успеха

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

Сценарий 4. Управление OOS и доступностью товара

Бизнес-ситуация

Утро среды, среднее время приезда товара по плану составляет два дня. Категорийный менеджер видит в BI, что по категории «Молочные продукты» три SKU вышли на нулевой остаток в шести магазинах одного кластера. Если ничего не делать, в выходные (пиковый день по категории) на полке будут пустые места. Прямые потери от классического OOS в продуктовом ритейле находятся на уровне 4% от выручки категории, и по индустриальным оценкам это многократно подтверждается. До четвёртого июня (пятницы) короткий период, в который нужно либо переключиться на альтернативный РЦ, либо подгонять экстренный заказ, либо временно подменить SKU.

Участники

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

Текущий процесс

Менеджер замечает проблему сам в обычной утренней рутине, открыв BI. Это уже удача, потому что нередко проблема замечается, когда жалоба прилетает от регионального руководителя.
Звонит логисту. Тот в данный момент решает другую проблему. Обещает посмотреть.
Логист через час перезванивает. Альтернативный РЦ есть, но переключить машину туда займёт два дня, и к выходным товар поспеет в притык, а часть магазинов останется без него.
Менеджер звонит поставщику, договаривается об экстренной партии. Поставщик подтверждает, но fill rate у него в этом квартале уже 87%, доверия не стопроцентное.
Менеджер просит операционного руководителя кластера временно расширить выкладку соседних SKU. Тот соглашается, но без шума, потому что у них и так перевешивать каждую неделю жмут.
К пятнице картина следующая. На двух магазинах из шести товара нет, на четырёх есть, но мало. В выходные продажи категории в этом кластере проваливаются на 18% против обычного.
В понедельник менеджер делает разбор того, что произошло. Первичный вывод сводится к недопоставке. Второй вывод сводится к тому, что не успели переключиться. О том, что сигнал был во вторник вечером (а не в среду утром), узнают только когда смотрят логи.

Боли текущего процесса

Главное болит реактивность. OOS сегодня обнаруживается, когда уже почти поздно. Пока сигнал доходит до человека, окно для манёвра сокращается с 48 часов до 12, а на коротком окне почти все варианты дороже. Менеджер не делает выбор, а гасит то, что доступно.

Параллельно мешает разрозненность данных. Чтобы оценить серьёзность ситуации, менеджеру нужны одновременно остатки в магазинах, прогноз спроса, статус поставки, fill rate поставщика и календарь промо. Эти пять кусков информации лежат в четырёх разных системах, и одна только их сборка занимает у человека полчаса.

Хуже того, в текущем процессе плохо видна системность. Конкретный OOS воспринимается как «случай», и каждый эпизод закрывается отдельно. А то, что у конкретного поставщика fill rate на 8 п.п. ниже SLA уже три квартала подряд, остаётся паттерном, который никто не собирает в одном месте, просто потому, что разные люди видят разные эпизоды и каждый из них в своей голове считает «у меня было дважды».

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

Как процесс выглядит с Напарником

В платформе OOS перестаёт быть событием, которое замечает человек по утрам, и становится потоком, который ведут агенты.

Вторник, 18:30. Агент OOS видит, что по трём SKU в шести магазинах одного кластера прогноз остатка к утру среды уходит в ноль. С учётом календаря промо и сезонности по выходным это даст потерю выручки порядка 2.4 млн ₽ за уикенд. Запускает поиск решения.
Вторник, 18:35. Напарник менеджера приходит с уже собранным пакетом. «Прогноз OOS по 3 SKU в кластере N к утру среды. Альтернативный РЦ A позволяет переключение за 36 часов, успеваем. Поставщик может прислать экстренную партию физически, но fill rate у него за квартал 87%, рекомендую как страховку, не как основной вариант. Подмена соседними SKU согласована операционным руководителем кластера ещё в апреле. Оптимальный план состоит в переключении на РЦ A, страховочном заказе и расширении выкладки в шести магазинах. Запросить у Напарника логиста подтверждение?».
Вторник, 18:40. Менеджер подтверждает. Напарник логиста за десять минут получает добро от своего сотрудника. Переключение на РЦ A инициируется. Операционному руководителю кластера уходит уведомление с предложенной выкладкой.
Среда и пятница. Агент OOS отслеживает движение. Товар вышел с РЦ A в указанное время, доехал в магазины в пятницу к утру. Категорийный менеджер на этом этапе вообще не вовлечён, кроме одного автоматического статус-сообщения в среду вечером, что всё идёт по плану.
Выходные. Полка не пустая, продажи в норме. Менеджер о ситуации, которая в старой модели стоила бы ему всей недели, фактически только знает, что она была.
Понедельник. Напарник приносит короткий разбор. «Эпизод OOS вторник-пятница закрыт. Корневая причина в недопоставке от поставщика B, fill rate которого за последние шесть месяцев колеблется около 87%. С июля у нас семь похожих эпизодов по этому поставщику. Готов добавить в досье следующих переговоров с ним». Менеджер подтверждает.

Какие функциональные агенты участвуют

Главную работу делает агент OOS. Он и проактивно ловит проблему, и оркеструет варианты решения. К нему подключается агент прогнозирования (он даёт оценку спроса с учётом промо и сезонности, и без неё непонятно, насколько критична нехватка) и агент финансового эффекта, оценивающий стоимость каждого варианта в рублях. Параллельно идёт фоновая работа агента переговоров. Он не вмешивается в сам инцидент, но копит фактуру по поставщику для следующего разговора с ним. За уведомления и эскалации в этом сценарии отвечает алертный агент. Подробное устройство всех этих агентов лежит в 03-agents.

Какие данные используются

Из хранилища берутся остатки на РЦ и в магазинах, продажи и прогноз спроса. Из WMS приходят поставки, графики, фактические даты прихода и SLA поставщиков с разбивкой на fill rate, отказы и замены. К ним подключаются календарь промо и карта альтернативных маршрутов между РЦ. Карта маршрутов нужна, чтобы агент мог автоматически предложить переключение, а не просить логиста собрать варианты руками.

Какие решения принимаются

В моменте идут три связанных подтверждения от людей. Переключение машины на альтернативный РЦ (логист), экстренный заказ у поставщика (логист) и временное расширение выкладки соседних SKU (операционный руководитель кластера). На горизонте дольше принимается решение включить накопленный паттерн по fill rate этого поставщика в досье следующих переговоров с ним. Его принимает категорийный менеджер уже после того, как эпизод закрыт.

Где нужен human-in-the-loop

Любое физическое движение товара (переключение РЦ, экстренный заказ, подмена SKU) идёт через явный клик соответствующего сотрудника. Напарник готовит, человек подтверждает. На уровне Tier 3 со временем можно вынести в автономный режим тривиальные случаи, например стандартное переключение между двумя ближайшими РЦ при остатке ниже X дней, но это включается точечно, после периода доверия. Подробности лежат в 05-architecture, раздел «Human-in-the-loop».

Ожидаемый бизнес-эффект

Главный эффект состоит в снижении длинного OOS, то есть случаев, которые длятся больше суток. Именно они дают непропорционально большой вклад в потери. В индустриальных оценках на короткие OOS приходится около 14% потерянных продаж, а на длинные больше половины. Платформа делает так, что длинные OOS почти не возникают, потому что проблема обнаруживается в часы, а не в дни.

Второй эффект связан с возвратом фактуры в переговоры. Когда у менеджера есть систематическая картина по fill rate каждого поставщика, с разрезом по месяцам, SKU и кластерам, переговорная позиция меняется. Это, в свою очередь, входит в сценарий 1 как одна из самых сильных аргументационных цепочек.

Метрики успеха

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

Сценарий 5. Межфункциональная встреча через Напарников

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

Бизнес-ситуация

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

Участники

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

Текущий процесс

Сегодня это занимает по-человечески обидное количество шагов.

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

Боли текущего процесса

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

И самое скучное состоит в том, что на сборку самого факта встречи в календарях уходит несколько перепалок и рабочих часов трёх человек.

Как процесс выглядит с Напарниками

В новой модели встреча собирается между Напарниками, готовится автоматически, и люди приходят к делу.

Менеджер говорит своему Напарнику. «Поставь встречу с прайс-менеджером и руководителем промо на следующей неделе на 30 минут. Хочу обсудить летнее промо по линейке шоколадных конфет».
Напарник менеджера обращается к Напарникам прайс-менеджера и руководителя промо. Они между собой согласовывают слоты, проверяя у своих сотрудников предпочтения (кто-то не любит ставить встречи до 11:00, кто-то блокирует пятницу под планёрку). Через две минуты у менеджера в мессенджере приходит результат, что договорились на четверг 15:00, встреча поставлена, повестка добавлена.
Накануне встречи каждый из трёх Напарников готовит своему сотруднику короткий бриф под эту встречу, каждый со своей оптики. Категорийному менеджеру приходит сводка про линейку, что прирост 4% к прошлому году, две из трёх SKU участвовали в весеннем промо, ROI был 9% и -2%, и что поставщик в феврале просил +3% к закупочной цене, отбили. Прайс-менеджеру приходит сводка, что по этой линейке мы дороже конкурента в этом ценовом сегменте на 3%, что объясняет часть провала по объёму, и если уйти в промо ниже на 7%, выйдем на конкурентный уровень. Руководителю промо приходит сводка, что летний бюджет по кондитерке порезали на 15%, оптимально вложиться в две акции вместо обычных трёх, и тогда стоит решить, какую из обсуждаемых линеек брать.
Встреча. У всех троих перед глазами свой бриф. Никто не пересказывает контекст друг другу, он у всех в голове. Обсуждение начинается сразу с предмета. Брать ли линейку в летнее промо, какой формат, какой уровень скидки, как избежать каннибализации. За 30 минут принимается решение. Акция идёт, формат «вторая по полной цене», стартует в третью неделю июля, бюджет берётся с другой акции, которую решили в этом году не повторять.
После встречи Напарник категорийного менеджера фиксирует договорённости в виде задач. Подготовить запрос поставщику на дополнительные объёмы, согласовать с прайсом окончательную скидку, отправить в маркетинг бриф на креатив. Каждая задача попадает к нужному сотруднику через его Напарника. Никто из людей не тратит на эту обвязку ни минуты.

Какие функциональные агенты участвуют

Главную работу делает агент встреч и follow-up. Он бронирует, готовит повестку, фиксирует договорённости, ставит задачи. К нему подключаются предметные агенты в момент подготовки брифа. Для категорийного менеджера это агент промо, для прайс-менеджера агент конкурентного мониторинга, для руководителя промо агент финансового эффекта.

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

Какие данные используются

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

Какие решения принимаются

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

Где нужен human-in-the-loop

Согласование слотов, по сути, идёт без участия людей. Напарники договариваются между собой и приходят к сотрудникам уже с готовым предложением. Сотрудник может скорректировать. Постановка любых задач проходит через явное подтверждение того, кто их получает. Любая внешняя коммуникация (письмо в маркетинг, запрос поставщику) идёт через клик человека.

Ожидаемый бизнес-эффект

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

Метрики успеха

Самая операционная метрика измеряет время на постановку межфункциональной встречи. Оно должно перейти из «несколько перепалок и пара рабочих часов трёх человек» в минуты. Дальше работает доля встреч с автоматически сформированной повесткой и брифом, а также доля договорённостей, превратившихся в задачи в течение часа после встречи. Хорошим косвенным сигналом служит число повторных встреч на ту же тему. В текущем процессе их много, в новом становится заметно меньше.

Backlog сценариев

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

День категорийного менеджера

Не аналитический сценарий, а сюжетный. Один полный рабочий день человека с Напарником, от утреннего брифинга до вечернего проактивного разбора в фоне. Полезен на демо как обобщающая иллюстрация, в которой все остальные сценарии встречаются маленькими фрагментами. Заметка для будущей детализации лежит в 02-partner, раздел «Рабочий день менеджера с Напарником», там уже есть рабочий каркас.

Подготовка к ассортиментному комитету

Раз в квартал категорийный менеджер защищает изменения в матрице. Сценарий объединяет работу нескольких агентов, среди них ассортимент, финансовый эффект, конкурентный мониторинг, маржинальность, списания. Похож на разбор продаж, но горизонт длиннее и решения тяжелее. Листинг и делистинг относятся к необратимым шагам, и здесь особенно важна Tier 2 граница автономии.

Кризисная ситуация

Срыв поставки, пожар на РЦ, проблема с регуляторикой по группе SKU. Общая черта таких ситуаций в том, что внутренний таймер сжат до часов. Здесь хорошо видно ценность проактивного агента алертов и сценарий «9:00, утром в мессенджере уже забронирован антикризисный звонок», описанный в исходных материалах концепта. Подробное описание появится, когда будет понятно, какие именно типы кризисов наиболее частые у конкретного заказчика.

Онбординг нового менеджера

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

Подготовка управленческого summary

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

Поиск и распространение лучших практик

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

Документ описывает бизнес-сценарии. Пользовательская модель Напарника описана в 02-partner. Каталог функциональных агентов лежит в 03-agents. Архитектура и инструментальные политики разобраны в 05-architecture. Интеграции собраны в 06-integrations. Этапы внедрения и привязка сценариев к фазам описаны в 07-roadmap.