Перейти к основному содержимому

Деливери-трек

Деливери-трек — это сущность, которая описывает, как именно ИИ-инициатива или задача по развитию ИИ-продукта проходит путь от запроса до реализованного решения.

Если бизнес-воронка отвечает на вопрос:

Какую бизнес-задачу мы решаем и зачем?

то деливери-трек отвечает на вопрос:

Каким способом, через какие ИИ-продукты, артефакты, согласования и участников мы это реализуем?

Главная идея: у разных типов ИИ-продуктов может не быть одинакового delivery-процесса.

LLM-сценарий, RAG-сервис, ML-модель, код-агент, автоматизация процесса и прикладной ИИ-сервис требуют разной логики реализации. У них разные этапы, разные артефакты, разные критерии готовности, разные участники и разные согласования.

Зачем нужен деливери-трек​

В ИИ-портфеле могут одновременно существовать очень разные задачи.

Например:

  • подобрать промпт для корпоративной LLM;
  • подключить документы к RAG;
  • запустить пилот код-агента в ИТ-команде;
  • внедрить ML-модель в процесс принятия решений;
  • собрать прикладной сервис, который использует LLM, RAG, OCR и интеграции с внутренними системами.

Все эти задачи относятся к ИИ, но реализуются совершенно по-разному.

Проблема возникает, когда компания пытается управлять ими одинаково: одна форма ТЗ, один набор согласований, один проектный шаблон, одни критерии готовности, один путь до внедрения.

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

Деливери-трек решает эту проблему: он позволяет сохранять единый управленческий контур, но использовать разные маршруты реализации для разных типов ИИ-продуктов.

Главная логика​

В операционной модели есть два уровня.

1. Единая управленческая логика​

Для всех ИИ-задач должны быть понятны:

  • владелец;
  • цель;
  • ожидаемый эффект;
  • выбранный ИИ-продукт или тип решения;
  • статус реализации;
  • ключевые риски;
  • следующий gate;
  • решение: продолжаем, дорабатываем, масштабируем или останавливаем.

Это нужно, чтобы ИИ-функция могла управлять портфелем целиком.

2. Разные delivery-треки​

Но способ реализации должен зависеть от типа продукта.

Тип ИИ-продуктаЛогика delivery
LLMПроверить, решается ли задача через промпт и правила использования
RAGПодготовить знания, загрузить в контур, проверить качество ответов и обновление базы
ML-модельПроверить данные, обучить модель, протестировать качество, встроить мониторинг
Код-агентНастроить доступы, правила работы с кодом, проверку изменений и code review
АвтоматизацияОписать процесс, настроить интеграции, обработать исключения
Прикладной ИИ-сервисРазработать отдельный продукт, который агрегирует несколько платформенных возможностей

Платформенные и прикладные деливери-треки​

Важное разделение — платформенные ИИ-продукты и прикладные ИИ-сервисы.

Delivery для платформенных продуктов​

Платформенные ИИ-продукты — это reusable-возможности, которые используются во множестве инициатив.

Например:

  • корпоративная LLM;
  • RAG-платформа;
  • ML-платформа;
  • код-агент;
  • агентная платформа;
  • OCR / распознавание документов.

Для них delivery чаще связан не с разработкой отдельного бизнес-приложения, а с проверкой применимости платформенной возможности к конкретному сценарию.

Например, для LLM-сценария delivery может быть относительно лёгким:

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

А для RAG delivery уже сложнее:

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

То есть даже внутри платформенных продуктов delivery отличается.

Delivery для прикладных ИИ-сервисов​

Прикладной ИИ-сервис — это уже не просто использование одной платформенной возможности.

Это отдельный пользовательский продукт, который может агрегировать несколько ИИ-компонентов.

Например:

  • сервис подготовки аналитической справки;
  • ассистент для обработки заявок;
  • инструмент генерации документов;
  • ассистент для проектного офиса;
  • сервис автоматизации внутреннего процесса.

Такой сервис может использовать внутри себя:

  • LLM;
  • RAG;
  • OCR;
  • ML-модель;
  • агентов и их оркестраторов;
  • интеграции с внутренними системами;
  • пользовательский интерфейс;
  • роли и права доступа.

Поэтому delivery для прикладного сервиса ближе к полноценной разработке продукта:

сценарий → архитектура → дизайн процесса → разработка → интеграции → тестирование → пилот → внедрение → эксплуатация

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

Почему нельзя сделать один универсальный деливери-трек​

Потому что разные ИИ-решения имеют разную природу сложности.

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

Если всё это загнать в один процесс, появятся две проблемы.

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

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

Поэтому правильная модель:

Единые правила для инициатив, но разные delivery-треки под разные типы ИИ-продуктов.

Что описывает деливери-трек​

Деливери-трек для каждого типа ИИ-продукта должен фиксировать:

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

Разные артефакты​

У разных delivery-треков разные артефакты.

Тип решенияПримеры артефактов
LLM-сценарийпромпт, тестовые запросы, критерии качества, инструкция пользователя
RAGсписок источников, база знаний, правила обновления, тесты качества ответов
ML-модельдатасет, описание признаков, метрики модели, отчёт тестирования, мониторинг
Код-агентправила доступа, сценарии использования, code review-процесс, ограничения
Автоматизациясхема процесса, интеграции, правила исключений, роли и доступы
Прикладной сервисТЗ, архитектура, UX, API, интеграции, тестирование, модель поддержки

Разные согласования​

Согласования тоже зависят от типа решения.

Например:

  • для LLM-сценария может быть достаточно владельца процесса и ИИ-функции;
  • для RAG нужен владелец базы знаний и согласование источников;
  • для ML-модели нужны владельцы данных и процесса принятия решения;
  • для код-агента нужны ИТ, архитектура, ИБ и владельцы репозиториев;
  • для прикладного ИИ-сервиса нужны архитектура, ИБ, эксплуатация, владельцы интегрируемых систем и бизнес-заказчик.

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

Разные участники​

Деливери-трек также задаёт состав участников.

В зависимости от типа решения могут участвовать:

  • владелец ИИ-продукта;
  • руководитель ИИ-инициативы;
  • бизнес-заказчик;
  • владелец процесса;
  • владелец данных;
  • владелец базы знаний;
  • архитектор;
  • ИБ;
  • ИТ;
  • эксплуатация;
  • ML-инженер;
  • разработчик;
  • аналитик;
  • команда поддержки;
  • конечные пользователи.

Важно, что не все участники нужны всегда. Смысл delivery-треков как раз в том, чтобы не собирать «всех на всё», а подключать нужных людей в нужный момент.

Место деливери-трека в операционной модели​

Деливери-трек находится между портфелем ИИ-инициатив и портфелем ИИ-продуктов.

С одной стороны, есть бизнес-потребность: нужно решить задачу подразделения.

С другой стороны, есть набор ИИ-продуктов: LLM, RAG, ML-платформа, код-агент, автоматизация, агентская платформа.

Деливери-трек связывает их между собой:

Какую задачу через какой ИИ-продукт и каким delivery-треком реализуем?

Короткая формула​

Деливери-трек — это маршрут реализации ИИ-решения, зависящий от типа ИИ-продукта.

Она показывает:

  • какие этапы нужны;
  • какие артефакты готовятся;
  • какие gate проверяются;
  • какие согласования требуются;
  • какие участники подключаются;
  • чем delivery LLM отличается от delivery RAG, ML-модели или прикладного ИИ-сервиса.