Дорожная карта внедрения

Последнее обновление: 5 июн. 2026 г., 19:30 ≈ 7 минут чтения

Статус: черновик — не показываем

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

Из этого раздела вы узнаете

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

Коротко

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

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

Этапы внедрения

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

Фаза 0, подготовка. Здесь нет ещё ни одного работающего Напарника, зато закладывается всё, без чего пилот не поедет. Команда внедрения вместе с ИТ заказчика выбирает мессенджер, согласует модель развёртывания и доступы, фиксирует Tier-модель автономии (см. 05-architecture) и договаривается о метриках успеха. Параллельно назначается куратор организационной памяти и владелец бизнес-сценария. Организационная часть этой фазы разобрана ниже в разделе «Организационные условия успеха».
Фаза 1, пилот. Команда внедрения запускает узкий контур на нескольких менеджерах-добровольцах. Обычно это операционный и аналитический уровни Напарника, два-три приоритетных сценария из 04-usecases и минимальный набор интеграций. Цель фазы — получить первый видимый эффект на реальной работе и собрать обратную связь от людей.
Фаза 2, расширение. Контур растёт. Команда подключает новые функциональные агенты из каталога, операционные сценарии (OOS, недопоставки) и новые интеграции к операционным системам через выгрузки в хранилище, а затем — коммуникационный уровень Напарника с профилями контрагентов и подсказками на встречах.
Фаза 3, масштабирование. Платформа выходит за пределы первого подразделения, и включается мультиагентный уровень. Напарники начинают разговаривать между собой по управляемой политике, появляется коллективная память с куратором, дозревает управление. На этой фазе становятся значимыми управление стоимостью и операционная поддержка на стороне заказчика.

Приоритетные сценарии для старта

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

Разбор падения продаж по категории

фаза 1

Сценарий 2 опирается на хранилище и BI, которые у крупной сети обычно уже зрелые. Эффект на скорости разбора виден почти сразу, и под него не нужны операционные интеграции.

Подготовка к переговорам с поставщиком

фаза 1

На Сценарии 1 виден прямой P&L-эффект на бэк-марже. Часть данных по поставкам и SLA приходит из хранилища, поэтому ERP и WMS на старте не нужны.

Операционные сценарии (управление OOS, кризисные ситуации) и межфункциональную координацию подключаем на следующих фазах. Они дают много ценности, но требуют более зрелых интеграций и наработанного доверия к автономным действиям. Полный список сценариев со статусами лежит в 04-usecases, раздел «Карта сценариев».

Приоритетные интеграции для старта

Стартовый набор интеграций должен закрывать выбранные сценарии и не упираться в инфраструктуру, которой у заказчика ещё нет. Подробный разбор лежит в 06-integrations, раздел «Приоритетные интеграции для MVP». Если коротко, на старте нужны хранилище и BI как источник аналитики, RAG поверх регламентов и прецедентов, корпоративный мессенджер с почтой и календарём, а также таск-трекер для фиксации договорённостей.

Этот набор сознательно не включает ERP, WMS и системы ценообразования. Данные о поставках и SLA на старте берём из хранилища через регулярные выгрузки, поэтому прямое подключение бизнес-критичных систем оставляем на более поздние фазы.

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

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

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

Универсального ROI у платформы нет. Финальная цифра зависит от того, какие сценарии входят в пилот, какая стартовая зрелость данных у заказчика и какие процессы он готов пересобрать. Поэтому набор метрик и их пороги мы привязываем к стандартному пресейл-процессу и определяем под конкретного заказчика.

Организационные условия успеха

Техническое внедрение само по себе не даёт полного эффекта. Платформа требует организационной готовности, и эту часть лучше начинать на Фазе 0, а не оставлять на потом.

Куратор организационной памяти

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

Согласование с комплаенсом

Tier-модель автономии, политики хранения данных и доступ к журналу аудита согласуются с информационной безопасностью заранее. Особенно это касается Tier 3, где каждый автономный сценарий проходит отдельную санкцию.

Готовность пересобрать процессы

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

Менеджеры-добровольцы

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

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

Открытые вопросы

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

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

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

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

В пилот мы сознательно берём аналитические сценарии на зрелых данных, а проактивность, операционные действия и межнапарниковую коммуникацию переносим на Фазы 2–3. Но именно отложенные возможности и составляют отличие Эпохи 4 от уже знакомых заказчику BI и функциональных агентов. Получается, что в первой фазе заказчик видит как раз самую слабую часть дифференциации, и скептичный заказчик вправе спросить, чем разбор падения продаж принципиально лучше связки «BI плюс text2SQL», которая у него, возможно, уже есть. Как доказать ценность именно платформенного слоя на узком аналитическом пилоте, не дожидаясь поздних фаз, концепт пока не формулирует.

📄 Скачать эту страницу в Markdown (.mdx) — для ИИ-агентов и оффлайн-чтения