Сущности
Сущности задают управленческий контур операционной модели: что ИИ-функция принимает в работу, как оценивает, через что реализует, где контролирует риски и как фиксирует результат.
Единая модель сущностей нужна, чтобы ИИ-функция, бизнес, ИТ, данные, архитектура, ИБ и руководство работали в одной картине мира: от первичного спроса до подтвержденного эффекта. Без этого невозможно сопоставлять инициативы, принимать решения по единым правилам и видеть, где создается ценность, а где процесс застрял.
1. Карта сущностей
| Сущность | Класс | Зачем нужна | Владелец |
|---|---|---|---|
| ИИ-идея | Спрос | Зафиксировать первичный спрос или гипотезу. | Инициатор, бизнес. |
| ИИ-инициатива | Спрос | Управлять бизнес-проблемой, ценностью, статусом и решением. | Бизнес-владелец, ИИ-функция. |
| ИИ-продукт | Реализация | Дать переиспользуемую возможность для класса задач. | Владелец ИИ-продукта. |
| Деливери-трек | Реализация | Определить путь реализации под тип ИИ-продукта. | Владелец ИИ-продукта, деливери-лид. |
| Контрольная точка (gate) | Контроль | Проверить готовность к переходу. | ИИ-функция, комитет, профильные функции. |
| Артефакт | Контроль | Зафиксировать состояние или доказательство готовности. | Ответственный за этап. |
| Риск | Контроль | Определить глубину контроля и ограничения. | ИБ, комплаенс, данные, архитектура, бизнес. |
| Эффект | Результат | Связать внедрение с измеримой пользой. | Бизнес-владелец, финансы, ИИ-функция. |
2. Четыре класса объектов
Главная ошибка старой модели сущностей — складывать всё в одну корзину. Сущности операционной модели делятся на четыре класса, и управляются они по-разному.
| Класс | Что входит | Управленческий смысл |
|---|---|---|
| Объекты спроса | ИИ-идея, ИИ-инициатива. | Что бизнес хочет изменить. |
| Объекты реализации | ИИ-продукт, деливери-трек. | Через что и каким способом реализуем. |
| Объекты контроля | Контрольная точка, артефакт, риск. | Почему можно или нельзя двигаться дальше. |
| Объекты результата | Эффект (ожидаемый и подтвержденный). | Что изменилось для бизнеса. |
Если эти классы не развести, платформа превращается в большую форму на 80 полей: пользователь не понимает, что он заполняет — описание идеи, проектный план, риск-опросник или отчет об эффекте.
Дальше сущности описаны по этим четырем классам.
3. Объекты спроса: идея и инициатива
ИИ-идея
ИИ-идея — это первичная гипотеза: «здесь ИИ может помочь». Идея еще не обязана быть полной, доказанной или готовой к реализации.
Минимально у идеи должны быть проблема, инициатор, область бизнеса и предварительное ожидание пользы. Всё остальное можно уточнять позже.
ИИ-инициатива
ИИ-инициатива — основная единица управления спросом и ценностью. Она появляется, когда идея получила минимальное описание и стала предметом оценки.
У инициативы должны быть бизнес-проблема, владелец результата, текущий процесс, ожидаемый эффект, пользователи, ограничения, статус бизнес-воронки и решение по маршрутизации.
Инициатива не равна проекту. Она может стать быстрым пилотом, подключением к готовому ИИ-продукту, полноценной разработкой, экспериментом или частью большой программы.
Внутри инициативы важно описать сценарий применения: кто пользователь, какое действие он выполняет, какие данные нужны, какой результат получает и как проверяется качество. Это не отдельная сущность, а обязательный срез инициативы, без которого она остается лозунгом.
Например, «внедрить ИИ в HR» — слишком размыто. «Автоматически сравнивать резюме с профилем вакансии по согласованным критериям и отдавать рекрутеру объяснимый shortlist» — уже нормальное описание применения внутри инициативы.
Инициатива движется по единой для всех инициатив бизнес-воронке — с возможным отклонением на любом этапе. Статус воронки — это свойство инициативы, а не отдельная сущность; как именно инициатива движется по этапам, описывает раздел Процессы.
4. Объекты реализации: продукт и деливери-трек
ИИ-продукт
ИИ-продукт — это переиспользуемая возможность, через которую реализуются инициативы одного класса: корпоративная LLM, RAG-платформа, ML-платформа, код-агент, документный ИИ, платформа автоматизации или прикладной ИИ-сервис.
ИИ-продукт должен иметь владельца, область применения, ограничения, правила подключения новых сценариев, модель поддержки, roadmap и метрики использования.
Деливери-трек
Деливери-трек отвечает на вопрос: как именно выбранное решение будет создано, проверено и внедрено. Один и тот же этап бизнес-воронки Деливери означает разную работу в зависимости от типа решения:
| Тип решения | Что проверяется в деливери-треке |
|---|---|
| LLM-сценарий | Промпт, ограничения, качество ответов, инструкция пользователя. |
| RAG | Источники, актуальность знаний, права доступа, качество поиска и ответов. |
| ML-модель | Данные, признаки, обучение, метрики, мониторинг, drift. |
| ИИ-агент | Действия, доступы, ограничения, журналирование, human-in-the-loop. |
| Автоматизация процесса | Схема процесса, интеграции, исключения, роли и контроль результата. |
| Прикладной ИИ-сервис | UX, API, архитектура, интеграции, эксплуатация, поддержка. |
5. Объекты контроля: точка, артефакт, риск
Контрольная точка (gate)
Контрольная точка — это не комитет ради комитета. Это правило перехода: можно ли двигать инициативу дальше. Gate привязан к переходу между этапами, а не к странице в документе, и опирается на артефакты как на доказательства готовности.
Что именно проверяется на каждом переходе — владелец, понятная проблема, выбранный ИИ-продукт, оценка данных, риски, критерии пилота, модель поддержки — задает раздел Процессы.
Артефакт
Артефакт — это доказательство состояния. Не «документ ради документа», а след решения: карточка инициативы, описание применения, risk review, архитектурное заключение, план пилота, отчет об эффекте.
Хороший артефакт отвечает на один вопрос: какое решение теперь можно принять?
Риск
Риск определяет глубину контроля. Внутренний LLM-сценарий для черновиков и агент с доступом к продуктивным системам не должны проходить одинаковый маршрут.
Риск влияет на gate, состав участников, обязательные артефакты, ограничения пилота и решение о внедрении.
6. Объекты результата: эффект
Эффект — это не обещание в презентации. Это измеримая польза, которую можно проверить после внедрения.
- 1Ожидаемый эффект
- 2Пилот / внедрение
- 3Измерение факта
| Статус | Управленческое решение |
|---|---|
| Эффект подтвержден | Масштабировать или поддерживать |
| Эффект не подтвержден | Доработать, остановить или изменить сценарий |
Пример:
- Ожидаемый эффект: сократить время подготовки аналитической справки с 2 часов до 30 минут.
- Подтвержденный эффект: после пилота среднее время сократилось до 35 минут на выборке из 20 задач.
- Управленческое решение: масштабировать на похожие подразделения или доработать качество источников.
Без сущности «эффект» операционная модель превращается в учет активности: сколько идей собрано, сколько пилотов запущено, сколько встреч проведено.
7. Как сущности связаны
Ценность создает не отдельная сущность, а связи между ними. Базовые правила:
| Связь | Правило |
|---|---|
| ИИ-идея → ИИ-инициатива | Не каждая идея становится инициативой. |
| ИИ-инициатива → ИИ-продукт | Инициатива может использовать один или несколько ИИ-продуктов. |
| ИИ-продукт → ИИ-инициатива | Один ИИ-продукт обслуживает много инициатив. |
| ИИ-продукт → деливери-трек | У продукта может быть типовой деливери-трек. |
| Контрольная точка → переход | Gate относится к переходу между этапами, а не просто к странице в документе. |
| Артефакт → контрольная точка | Артефакт подтверждает готовность или фиксирует решение. |
| Риск → контроль | Чем выше риск, тем глубже проверка. |
| Эффект → решение | Подтвержденный эффект ведет к масштабированию, поддержке, доработке или закрытию. |
8. Антипример
Плохая операционная модель выглядит так:
- идеи собираются в общей таблице;
- пилоты запускаются без единой бизнес-воронки;
- ИИ-продукты закупаются отдельно от спроса;
- сценарии применения не описаны;
- контрольные точки заменены встречами;
- риски оцениваются каждый раз заново;
- эффект обсуждается постфактум и без исходных метрик.
В результате ИИ-функция становится диспетчером хаоса: принимает заявки, бегает за согласованиями, собирает статусы вручную и не может доказать, что внедрение ИИ меняет бизнес.
9. Правильная сборка
Собранные вместе, сущности образуют управляемый путь инициативы — от бизнес-проблемы до решения:
- 1Бизнес-проблема
- 2ИИ-идея
- 3ИИ-инициатива
- 4ИИ-продукт
- 5Деливери-трек
- 6Gate: допуск к деливери
- 7Пилот / реализация
- 8Gate: готовность к эффекту
- 9Измерение эффекта
- 10Итоговое решение
Эта сборка важнее длинного списка полей: операционная модель управляет не отдельными документами, а движением от бизнес-проблемы к подтвержденному результату. Так ИИ перестает быть набором разрозненных экспериментов и становится управляемым портфелем — видно, что пришло из бизнеса, через какой ИИ-продукт реализуется, какие риски ограничивают движение и какой эффект получен после внедрения.
10. Короткая формула раздела
Сущности операционной модели — это общий язык управления внедрением ИИ: от идеи и инициативы до продукта, деливери, риска и подтвержденного эффекта.
Коротко:
Роли показывают, кто управляет ИИ. Сущности показывают, чем именно управляет операционная модель.