Роли
Зачем нужны роли в портфеле ИИ-инициатив
ИИ-инициатива почти никогда не реализуется одной командой.
Даже если кажется, что «нужно просто подключить LLM» или «сделать RAG», в реальности инициатива затрагивает несколько контуров:
- бизнес-процесс;
- данные и документы;
- ИИ-продукты;
- ИТ-интеграции;
- безопасность;
- эксплуатацию;
- пользователей;
- оценку эффекта.
Поэтому для портфеля ИИ-инициатив важно заранее определить, кто за что отвечает.
Без этого инициатива быстро превращается в хаос: бизнес ждёт результата, ИТ ждёт требований, ИИ-команда ждёт доступов, безопасность подключается слишком поздно, а эффект никто не может подтвердить.
Главный принцип: у каждой инициативы должен быть владелец результата. ИИ-функция помогает провести инициативу через систему, но не должна становиться владельцем всех бизнес-эффектов.
Основные роли
1. Бизнес-заказчик
Бизнес-заказчик — это владелец бизнес-проблемы, ради которой запускается ИИ-инициатива.
Он отвечает не за техническую реализацию, а за смысл инициативы:
- какую проблему решаем;
- почему она важна;
- какой эффект ожидается;
- кто будет пользоваться решением;
- как решение будет встроено в процесс;
- кто подтвердит, что результат действительно полезен.
Бизнес-заказчик не обязан понимать, какой ИИ-продукт нужен: LLM, RAG, ML-модель, агент или автоматизация. Его задача — описать потребность и подтвердить ценность.
Главная ответственность: бизнес-смысл, эффект и внедрение в реальный процесс.
2. Руководитель ИИ-инициативы
Руководитель ИИ-инициативы — это роль, которая ведёт инициативу через бизнес-воронку: от идеи до завершения.
Он помогает превратить сырой запрос бизнеса в управляемую инициативу:
- уточняет проблему и целевой результат;
- помогает сформулировать гипотезу ценности;
- определяет, какие ИИ-продукты потенциально подходят;
- организует оценку реализуемости;
- собирает участников;
- ведёт инициативу по статусам;
- готовит материалы для stage gate;
- фиксирует решения, риски и следующие шаги;
- следит, чтобы инициатива не зависла между подразделениями.
Это не обязательно технический лидер. Скорее, это владелец управленческого движения инициативы.
Главная ответственность: провести инициативу через бизнес-воронку и довести её до полученного эффекта.
3. Владелец ИИ-продукта
Продуктовый владелец ИИ-продукта отвечает за тот ИИ-продукт, через который может быть реализована инициатива.
Например:
- корпоративная LLM;
- RAG-платформа;
- ML-платформа;
- инструмент для code agent;
- прикладной ИИ-сервис.
Его задача — понять, может ли существующий ИИ-продукт закрыть потребность бизнеса и что для этого нужно.
Он отвечает за вопросы:
- подходит ли продукт под задачу;
- какие ограничения есть у продукта;
- какие данные, документы или настройки нужны;
- можно ли решить задачу конфигурацией, промптом, RAG-базой, агентом или нужен отдельный сервис;
- какие доработки продукта потребуются;
- как инициатива повлияет на roadmap продукта.
Главная ответственность: связать бизнес-потребность с подходящим ИИ-продуктом или показать, что текущих продуктов недостаточно.
4. Владелец эффекта
Владелец эффекта — это человек со стороны бизнеса, который подтверждает, что инициатива дала результат.
Это может быть тот же человек, что и бизнес-заказчик, но не всегда.
Например, заказчиком может быть руководитель направления, а владельцем эффекта — руководитель процесса, финансовый контролёр или операционный владелец метрики.
Он отвечает за:
- исходную точку измерения;
- целевую метрику;
- способ подтверждения эффекта;
- факт использования решения;
- подтверждение экономии, выручки, снижения трудозатрат, ускорения процесса или повышения качества.
Главная ответственность: подтвердить, что инициатива принесла измеримый или качественно зафиксированный результат.
5. Пользователи / рабочая группа
Пользователи — это те, кто реально проверяет решение в работе.
Их роль критична, потому что ИИ-инициатива может быть технически реализована, но не принята в процесс.
Пользователи помогают понять:
- удобно ли решение;
- решает ли оно реальную задачу;
- где качество недостаточное;
- какие сценарии не покрыты;
- какие есть риски использования;
- что нужно изменить перед масштабированием.
Главная ответственность: дать практическую обратную связь и подтвердить применимость решения в реальной работе.
6. Смежные функции
Смежные функции подключаются в зависимости от типа инициативы и уровня риска.
Обычно это:
- ИТ;
- архитектура;
- информационная безопасность;
- владельцы данных;
- DWH / data-команды;
- юридическая функция;
- комплаенс;
- эксплуатация;
- поддержка.
Их задача — не «тормозить инициативу», а заранее проверить готовность решения к использованию в корпоративном контуре.
Они отвечают за:
- доступы;
- данные;
- интеграции;
- архитектурную совместимость;
- безопасность;
- требования к эксплуатации;
- регуляторные ограничения;
- поддержку после запуска.
Главная ответственность: обеспечить безопасное и устойчивое внедрение решения.
Дополнительные роли управления и контроля
В старой модели ролей были зафиксированы несколько ролей, которые важно не потерять.
| Роль | Зачем нужна |
|---|---|
| Инициатор | Формулирует первичную проблему и запускает карточку инициативы |
| Владелец данных | Отвечает за источники, качество и разрешение на использование данных |
| Безопасность | Проверяет ограничения доступа, конфиденциальность и контур обработки |
| Архитектор | Проверяет интеграции, эксплуатацию, наблюдаемость и откат |
| Финансы | Помогают подтвердить значимый экономический эффект |
| Портфельный комитет | Решает приоритеты, ресурсы, исключения и спорные переходы |
Эти роли не всегда нужны в каждой инициативе с первого дня, но перед delivery должны быть определены минимум бизнес-владелец, ответственный за продвижение, выбранный продукт и ограничения по данным/безопасности.
Роль ИИ-функции в портфеле инициатив
ИИ-функция не должна быть единственным исполнителем всех ИИ-инициатив.
Её роль — быть управляющим и методологическим центром, который помогает бизнесу проходить путь от идеи до эффекта.
ИИ-функция отвечает за:
- правила входа инициатив в портфель;
- бизнес-воронку инициатив;
- маршрутизацию инициатив по ИИ-продуктам;
- приоритизацию;
- stage gate;
- прозрачность статусов;
- синхронизацию участников;
- контроль артефактов;
- накопление повторно используемых решений;
- фиксацию эффекта.
ИИ-функция не должна:
- владеть эффектом вместо бизнеса;
- согласовывать каждую мелочь вручную;
- заменять безопасность, архитектуру или финансы;
- тянуть в delivery инициативы без владельца.
Иначе говоря, ИИ-функция не просто «делает проекты». Она строит систему, в которой ИИ-инициативы становятся управляемым потоком.
Базовая карта ролей
| Роль | За что отвечает |
|---|---|
| Бизнес-заказчик | Проблема, ценность, внедрение в процесс |
| Руководитель ИИ-инициативы | Движение инициативы по бизнес-воронке |
| Продуктовый владелец ИИ-продукта | Подбор и развитие подходящего ИИ-продукта |
| Владелец эффекта | Подтверждение результата и пользы |
| Пользователи / пилотная группа | Проверка применимости в реальной работе |
| Смежные функции | Данные, ИТ, безопасность, архитектура, эксплуатация |
| ИИ-функция | Управление портфелем, правила, stage gate, прозрачность |
Матрица ответственности
| Действие | Основная роль | Участвуют |
|---|---|---|
| Создать инициативу | Инициатор | ИИ-помощник, ИИ-функция |
| Уточнить проблему и эффект | Бизнес-заказчик | Инициатор, ИИ-функция |
| Проверить похожие инициативы | ИИ-функция | ИИ-помощник |
| Выбрать продукт | ИИ-функция | Владелец ИИ-продукта, архитектор |
| Проверить данные | Владелец данных | Безопасность, delivery-команда |
| Проверить безопасность | Безопасность | ИИ-функция, владелец данных |
| Подготовить delivery | Руководитель ИИ-инициативы | Владелец ИИ-продукта, delivery-команда |
| Проверить архитектуру | Архитектор | Владелец ИИ-продукта, безопасность |
| Подтвердить эффект | Владелец эффекта | Финансы, ИИ-функция |
| Принять исключение | Портфельный комитет | Спонсор, ИИ-функция, риск-функции |
Минимальные роли по этапам
| Этап | Обязательные роли |
|---|---|
| Новая | инициатор, ИИ-функция |
| Оценка | бизнес-заказчик, ИИ-функция, владелец ИИ-продукта при наличии маршрута |
| Delivery | руководитель ИИ-инициативы, владелец ИИ-продукта, владелец данных, безопасность при необходимости |
| Ожидает эффекта | владелец эффекта, ИИ-функция, финансы при значимом эффекте |
| Поддержка | владелец ИИ-продукта, эксплуатационный владелец, бизнес-заказчик |
Роль ИИ-помощника
ИИ-помощник помогает ролям работать быстрее:
- инициатору — сформулировать бриф;
- ИИ-функции — проверить заполненность и похожие инициативы;
- финансисту — подготовить черновик модели эффекта;
- безопасности — собрать исходные вопросы;
- архитектору — подготовить описание интеграций;
- руководителю инициативы — сформировать задачи.
Но помощник не является владельцем решения и не заменяет права доступа. Его действия должны подчиняться тем же правилам, что и действия пользователя.
Антипаттерны
Плохая ролевая модель:
- у инициативы нет бизнес-владельца;
- ИИ-функция отвечает за эффект вместо подразделения;
- руководитель инициативы назначен формально;
- безопасность подключается в конце;
- владелец данных неизвестен;
- комитет принимает решения без критериев;
- никто не отвечает за поддержку после запуска.
Хорошая ролевая модель делает ответственность видимой до delivery, а не после первого сбоя.
Ключевая идея раздела
Портфель ИИ-инициатив — это не список идей и не набор разрозненных пилотов.
Это управляемый контур, где каждая инициатива имеет:
- владельца проблемы;
- владельца движения;
- владельца продукта;
- владельца реализации;
- владельца эффекта;
- участников согласования;
- понятный статус в бизнес-воронке.
Тогда ИИ-инициативы перестают быть хаотичными экспериментами и становятся управляемым способом превращать бизнес-потребности в работающие ИИ-решения.