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