---
title: "Дорожная карта внедрения"
description: "Как разворачивать платформу во времени. Фазы внедрения от подготовки до масштабирования, приоритетные сценарии и интеграции для старта, метрики успеха и организационные условия, без которых техническое внедрение не даёт полного эффекта."
sidebar:
order: 8
label: "07. Дорожная карта"
---
import { Card, CardGrid, Steps, Badge } from '@astrojs/starlight/components';
Документ собирает агентов, сценарии и интеграции в последовательность фаз внедрения. Он отвечает на вопрос, в каком порядке разворачивать платформу, с чего начинать пилот, как понять, что он удался, и какие организационные условия нужны, чтобы техническое внедрение дало эффект.
## Из этого раздела вы узнаете
- из каких фаз состоит внедрение, от подготовки до масштабирования, и почему они перекрываются
- какие сценарии разумно брать в пилот первыми и почему аналитические
- какие интеграции нужны на старте, а какие сознательно переносятся на потом
- как оценивать пилот по метрикам скорости, денег и пользовательского принятия
- какие организационные условия должны быть закрыты, иначе техническое внедрение буксует
---
## Коротко
Платформу разворачивают поэтапно, а не одним релизом. Она растёт по фазам, и каждая следующая опирается на работающие интеграции, накопленную обратную связь и выстроенные правила безопасности предыдущей. Эта логика повторяет лестницу уровней зрелости Напарника из [02-partner](/02-partner/#уровни-зрелости-ии-напарника), но смотрит на неё со стороны проекта внедрения, а не со стороны сотрудника.
Старт почти всегда устроен одинаково: один Напарник, четыре-пять [функциональных агентов](/03-agents), одна-две понятные интеграции и небольшая группа менеджеров-добровольцев в одном подразделении. Дальше контур расширяется по мере того, как заказчик видит ценность и подтягиваются источники данных.
:::tip[Главный тезис документа]
Платформу разворачивают поэтапно, а не одним релизом. Начинать нужно с узкого пилота на зрелых данных и быстром аналитическом эффекте, а расширение контура и [межнапарниковую коммуникацию](/05-architecture/#межнапарниковая-коммуникация-a2a) подключать только после того, как заказчик увидел ценность и закрыл организационные условия.
:::
---
:::caution[Статус документа]
Это черновик-скелет. Разделы намечены, но детальная проработка фаз, цифр и чек-листов появляется при подготовке к конкретному пилоту. Пока документ задаёт каркас и связывает остальные разделы концепта между собой.
:::
## Этапы внедрения
Ниже укрупнённая последовательность фаз. Это карта зависимостей, а не жёсткий календарный план. На реальном проекте фазы перекрываются, потому что базовый аналитический контур обычно поднимается одновременно с операционным помощником.
1. Фаза 0, подготовка. Здесь нет ещё ни одного работающего [Напарника](/02-partner), зато закладывается всё, без чего пилот не поедет. Команда внедрения вместе с ИТ заказчика выбирает мессенджер, согласует модель развёртывания и доступы, фиксирует Tier-модель автономии (см. [05-architecture](/05-architecture/#tier-модель-автономии)) и договаривается о метриках успеха. Параллельно назначается куратор [организационной памяти](/05-architecture/#память-и-контекст) и владелец бизнес-сценария. Организационная часть этой фазы разобрана ниже в разделе «Организационные условия успеха».
2. Фаза 1, пилот. Команда внедрения запускает узкий контур на нескольких менеджерах-добровольцах. Обычно это операционный и аналитический уровни Напарника, два-три приоритетных сценария из [04-usecases](/04-usecases) и минимальный набор интеграций. Цель фазы — получить первый видимый эффект на реальной работе и собрать обратную связь от людей.
3. Фаза 2, расширение. Контур растёт. Команда подключает новые функциональные агенты из каталога, операционные сценарии (OOS, недопоставки) и новые интеграции к операционным системам через выгрузки в хранилище, а затем — коммуникационный уровень Напарника с [профилями контрагентов](/05-architecture/#профили-контрагентов) и подсказками на встречах.
4. Фаза 3, масштабирование. Платформа выходит за пределы первого подразделения, и включается мультиагентный уровень. Напарники начинают [разговаривать между собой по управляемой политике](/05-architecture/#межнапарниковая-коммуникация-a2a), появляется коллективная память с куратором, дозревает управление. На этой фазе становятся значимыми [управление стоимостью](/05-architecture/#управление-стоимостью) и операционная поддержка на стороне заказчика.
---
## Приоритетные сценарии для старта
В пилот разумно брать сценарии, которые быстро дают видимый эффект и не требуют интеграций, которые невозможно собрать за разумное время. Из [04-usecases](/04-usecases) на эту роль лучше всего ложатся два аналитических сценария.
[Сценарий 2](/04-usecases/#сценарий-2-разбор-падения-продаж-по-категории) опирается на хранилище и BI, которые у крупной сети обычно уже зрелые. Эффект на скорости разбора виден почти сразу, и под него не нужны операционные интеграции.
На [Сценарии 1](/04-usecases/#сценарий-1-подготовка-к-переговорам-с-поставщиком) виден прямой P&L-эффект на бэк-марже. Часть данных по поставкам и SLA приходит из хранилища, поэтому ERP и WMS на старте не нужны.
Операционные сценарии (управление OOS, кризисные ситуации) и межфункциональную координацию подключаем на следующих фазах. Они дают много ценности, но требуют более зрелых интеграций и наработанного доверия к автономным действиям. Полный список сценариев со статусами лежит в [04-usecases, раздел «Карта сценариев»](/04-usecases/#карта-сценариев).
---
## Приоритетные интеграции для старта
Стартовый набор интеграций должен закрывать выбранные сценарии и не упираться в инфраструктуру, которой у заказчика ещё нет. Подробный разбор лежит в [06-integrations, раздел «Приоритетные интеграции для MVP»](/06-integrations/#приоритетные-интеграции-для-mvp). Если коротко, на старте нужны хранилище и BI как источник аналитики, RAG поверх регламентов и прецедентов, корпоративный мессенджер с почтой и календарём, а также таск-трекер для фиксации договорённостей.
Этот набор сознательно не включает ERP, WMS и системы ценообразования. Данные о поставках и SLA на старте берём из хранилища через регулярные выгрузки, поэтому прямое подключение бизнес-критичных систем оставляем на более поздние фазы.
---
## Метрики успеха
Пилот оцениваем по заранее согласованному набору метрик, который команда внедрения и заказчик фиксируют ещё на Фазе 0. Без этой договорённости разговор о результате после пилота превращается в спор об ощущениях. Метрики удобно разносить на операционные, бизнес-метрики и пользовательские. Полный каталог с примерами и способами замера лежит в [02-partner, раздел «Метрики ценности ИИ-Напарника»](/02-partner/#метрики-ценности-ии-напарника).
Эффект смотрим с нескольких сторон сразу. По скорости это время на типовой аналитический запрос и путь от аномалии до оповещения. На деньгах эффект виден по марже категории и дополнительной бэк-марже в переговорах. А чтобы понять, прижился ли инструмент у людей, собираем NPS менеджеров и долю задач, в которых сотрудник идёт к Напарнику.
Универсального ROI у платформы нет. Финальная цифра зависит от того, какие сценарии входят в пилот, какая стартовая зрелость данных у заказчика и какие процессы он готов пересобрать. Поэтому набор метрик и их пороги мы привязываем к стандартному пресейл-процессу и определяем под конкретного заказчика.
---
## Организационные условия успеха
Техническое внедрение само по себе не даёт полного эффекта. Платформа требует организационной готовности, и эту часть лучше начинать на Фазе 0, а не оставлять на потом.
Нужна роль, формально ответственная за качество [коллективной памяти](/05-architecture/#коллективная-память). Обычно это руководитель направления или сильный эксперт. Без куратора коммерчески значимые паттерны либо не попадают в общий контур, либо попадают туда без проверки.
[Tier-модель автономии](/05-architecture/#tier-модель-автономии), политики хранения данных и доступ к журналу аудита согласуются с информационной безопасностью заранее. Особенно это касается Tier 3, где каждый автономный сценарий проходит отдельную санкцию.
Часть ценности раскрывается только тогда, когда заказчик готов формализовать процессы вокруг новой модели работы. Если процесс остаётся прежним, [Напарник](/02-partner) ускоряет отдельные операции, но не меняет темп функции целиком.
Пилот стартует на тех, кому это интересно. Лучшие менеджеры, перегруженные сильнее всех, дают и самую честную обратную связь, и самый заметный эффект.
Отдельно стоит модель совместной эксплуатации. К шестому-двенадцатому месяцу внедрения Glowbyte и заказчик распределяют роли между собой. Glowbyte остаётся архитектурным партнёром и развивает каталог агентов и сценариев, а ИТ-команда заказчика постепенно берёт на себя операционную поддержку платформы. Эту модель важно проговорить с самого начала, потому что от неё зависит передача знаний на протяжении всего проекта.
---
## Открытые вопросы
Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
:::caution[Карта зависимостей без календаря трудно превращается в обязательство]
Длительности фаз и календарные сроки заданы намеренно условно («к шестому-двенадцатому месяцу»), потому что зависят от стартовой зрелости заказчика. Но заказчик на пресейле почти всегда хочет дату и фиксированный объём первой фазы. Как давать дорожную карту, по которой можно зафиксировать обязательства и бюджет, не подменяя их вилкой «зависит от вас», концепт пока не формулирует.
:::
:::caution[Фаза 0 несёт орг-риск, а не технический]
Фазовая модель предполагает перекрытие фаз, но всё внедрение упирается в Фазу 0, а именно в куратора организационной памяти, согласование с комплаенсом и готовность пересобрать процессы. Если у заказчика эти условия не закрыты, пилот технически запускается, но не даёт обещанного эффекта, и причина лежит на стороне заказчика, а не платформы. Концепт пока не отвечает, как заранее отличить заказчика, у которого Фаза 0 реально закроется, от того, кто формально подпишет условия и не выполнит.
:::
:::caution[Модель совместной эксплуатации несёт коммерческое напряжение]
Разделение ролей между Glowbyte и ИТ-командой заказчика к шестому-двенадцатому месяцу намечено, но не детализировано. За этой передачей стоит коммерческий конфликт. Где проходит граница между «архитектурным партнёрством» Glowbyte и операционной самостоятельностью заказчика и как устроена экономика поддержки после неё. Если передать слишком рано, страдает качество, а если слишком поздно, это выглядит как удержание заказчика на сопровождении.
:::
:::caution[Пилот показывает не то, чем платформа отличается]
В пилот мы сознательно берём аналитические сценарии на зрелых данных, а проактивность, операционные действия и межнапарниковую коммуникацию переносим на Фазы 2–3. Но именно отложенные возможности и составляют отличие Эпохи 4 от уже знакомых заказчику BI и функциональных агентов. Получается, что в первой фазе заказчик видит как раз самую слабую часть дифференциации, и скептичный заказчик вправе спросить, чем разбор падения продаж принципиально лучше связки «BI плюс [text2SQL](/03-agents/#5-text2sql)», которая у него, возможно, уже есть. Как доказать ценность именно платформенного слоя на узком аналитическом пилоте, не дожидаясь поздних фаз, концепт пока не формулирует.
:::