Модель контрольных точек
Назначение
Документ описывает модель контрольных точек (gate) платформы ИИ Конвейер: какие этапы проходит инициатива, какие проверки выполняются перед переходом, какие управленческие решения принимаются и на каких данных они опираются.
Модель опирается на функционал платформы: бизнес-воронку инициатив, деливери-треки ИИ-продуктов, настраиваемые правила переходов, обязательные поля, проверку похожих инициатив, задачи, артефакты и аналитику.
Кто утверждает решения — в рамках принятия решений. Логика gate, критерии и типы решений — на этой странице.
Основные идеи
- Этап — состояние инициативы в бизнес-воронке: новая, оценка, деливери, ожидание эффекта, поддержка, закрытие или отклонение.
- Контрольная точка (gate) — проверка перед переходом на следующий этап. Она должна быть понятной, проверяемой и заранее известной участникам.
- Правило перехода — настройка платформы, которая определяет, из какого этапа в какой можно перейти.
- Обязательные поля — минимальный набор данных, без которого решение нельзя считать управляемым.
- Деливери-воронка — этапы деливери внутри выбранного ИИ-продукта. У разных ИИ-продуктов эти этапы могут отличаться.
- Решение — зафиксированный итог контрольной точки. У каждой инициативы на gate возможны четыре типа исхода:
- продвигать — инициатива готова к следующему этапу;
- доработать — потенциал есть, но не хватает данных, владельца, ИИ-продукта или артефактов;
- остановить — инициатива слабая, рискованная, дублирующая или не имеет эффекта;
- масштабировать — результат подтверждён и применим шире одного процесса.
Решение должно опираться на карточку инициативы, задачи, проверки, артефакты и аналитику портфеля.
Как это работает
Инициатива движется по бизнес-воронке:
- 1Новая
- 2Оценка
- 3Деливери
- 4Ожидает эффекта
- 5На поддержке / Закрыта
Инициатива может быть отклонена, если ценность не подтверждается, риск слишком высок, нет данных, нет владельца или есть более приоритетные работы.
В платформе этим этапам соответствуют состояния NEW, ASSESSMENT, DELIVERY, AWAITING_EFFECT, ON_SUPPORT, CLOSED и REJECTED.
Контрольные точки настраиваются администратором ИИ-офиса через правила переходов, обязательные поля и видимость полей. Для перехода в деливери платформа уже поддерживает важные проверки: должен быть выбран продукт, должна быть выполнена проверка похожих инициатив, а предварительная проверка безопасности не должна иметь отрицательный результат.
Детали жизненного цикла — в жизненном цикле инициативы.
| Контрольная точка | Этап, к которому относится |
|---|---|
| КТ 1 | Новая |
| КТ 2 | Оценка |
| КТ 3 | Деливери |
| КТ 4 | Ожидает эффекта |
| КТ 5 | Поддержка или закрытие |
Карта контрольных точек
| Контрольная точка | Переход | Главный вопрос | Минимальные критерии | Владелец решения |
|---|---|---|---|---|
| КТ 1. Регистрация | проблема → новая инициатива | Стоит ли фиксировать идею в портфеле? | Есть проблема, инициатор, краткое описание, ожидаемый тип эффекта | ИИ-офис или руководитель направления |
| КТ 2. Допуск к оценке | новая → оценка | Достаточно ли данных, чтобы разбирать инициативу? | Заполнены базовые поля, понятен владелец, нет очевидного дубля | ИИ-офис |
| КТ 3. Допуск к деливери | оценка → деливери | Имеет ли смысл тратить команду и ресурс ИИ-продукта? | Выбран ИИ-продукт, выполнена проверка похожих инициатив, безопасность не отклонила, есть гипотеза эффекта и приоритет | Комитет или назначенный ответственный |
| КТ 4. Запуск ожидания эффекта | деливери → ожидает эффекта | Решение внедрено настолько, что можно измерять результат? | Деливери завершена, есть владелец процесса, определены метрики, дата проверки эффекта и источник данных | Владелец инициативы вместе с ИИ-офисом |
| КТ 5. Завершение или поддержка | ожидает эффекта → поддержка/закрыта | Эффект подтверждён и понятно, что делать дальше? | Рассчитан фактический эффект, есть решение о закрытии, поддержке, масштабировании или доработке | Бизнес-владелец, финансы, ИИ-офис |
| Отклонение | любой ранний этап → отклонена | Почему инициативу не продолжаем? | Указана причина, сохранена история решения, при необходимости предложен возврат или пересмотр | Ответственный за текущий этап |
Данные для решения
Минимальный набор данных на контрольной точке:
- описание бизнес-проблемы;
- ожидаемый эффект;
- владелец инициативы;
- ИИ-продукт;
- результат проверки похожих инициатив;
- приоритет;
- ограничения данных и безопасности;
- задачи и статус деливери;
- дата проверки эффекта;
- фактический результат после внедрения.
Если данных недостаточно, корректное решение — не «пропустить дальше», а вернуть инициативу на уточнение.
КТ 1. Регистрация инициативы
Цель — не доказать ценность, а зафиксировать идею так, чтобы она не потерялась и могла быть оценена.
Минимальный вход:
- бизнес-проблема;
- инициатор;
- подразделение или процесс;
- краткое описание идеи;
- предварительный тип эффекта.
Результат:
- создана карточка инициативы;
- стадия установлена как «Новая»;
- инициатива попала в портфель;
- при необходимости создан первичный набор задач.
КТ 2. Допуск к оценке
Цель — отделить сырой поток идей от инициатив, которые стоит разбирать содержательно.
Минимальные критерии:
- проблема описана через процесс и показатель;
- есть бизнес-владелец или понятный кандидат;
- указана ожидаемая ценность;
- инициатива не является очевидным дублем;
- нет явного запрета со стороны безопасности или данных.
Решения:
- перевести в оценку;
- вернуть на уточнение;
- отклонить с причиной;
- объединить с похожей инициативой.
Платформенная опора:
- карточка инициативы;
- проверка похожих инициатив;
- обязательные поля по этапу;
- история переходов.
КТ 3. Допуск к деливери
Это ключевая контрольная точка. Именно здесь инициатива перестаёт быть идеей и начинает потреблять ресурс команды, продукта и инфраструктуры.
Минимальные критерии:
- выбран ИИ-продукт;
- выполнена проверка похожих инициатив;
- предварительная проверка безопасности не имеет отрицательного результата;
- понятна гипотеза эффекта;
- указан приоритет;
- назначен руководитель проекта или ответственный за продвижение;
- определены ближайшие задачи деливери.
В платформе переход в деливери должен блокироваться, если не выбран ИИ-продукт или не выполнена обязательная проверка похожих инициатив. Если предварительная проверка безопасности имеет отрицательный результат, инициатива не должна идти в деливери без отдельного решения.
Решения:
- допустить к деливери;
- отправить на доработку оценки;
- сменить продукт;
- отложить из-за нехватки ресурсов;
- отклонить.
КТ 4. Запуск ожидания эффекта
Цель — убедиться, что решение не просто разработано, а готово к проверке результата в бизнес-процессе.
Минимальные критерии:
- завершён нужный этап деливери-трека;
- решение доступно пользователям или встроено в процесс;
- назначен владелец процесса после внедрения;
- определены исходное значение, целевое значение и фактический источник метрик;
- указана дата проверки эффекта;
- зафиксированы эксплуатационные ограничения и риски.
Решения:
- перевести в ожидание эффекта;
- оставить в деливери на доработку;
- перевести на поддержку без эффекта только как исключение;
- отклонить деливери, если решение не пригодно к использованию.
Платформенная опора:
- продуктовый деливери-трек;
- задачи инициативы;
- дата ожидаемого эффекта;
- аналитика просроченных инициатив в ожидании эффекта.
КТ 5. Завершение, поддержка или масштабирование
Цель — не закрыть карточку ради чистого реестра, а принять управленческое решение на основе фактического результата.
Минимальные критерии:
- эффект рассчитан по согласованной методике;
- понятно, какая часть эффекта относится именно к инициативе;
- финансовый или бизнес-владелец подтвердил расчёт;
- принято решение о дальнейшем режиме: закрыть, поддерживать, масштабировать, доработать или остановить.
Решения:
- закрыть как достигнутую цель;
- перевести на поддержку;
- масштабировать на другие процессы или подразделения;
- вернуть в деливери на доработку;
- закрыть без подтверждённого эффекта с причиной.
Отклонение инициативы
Отклонение — это нормальный результат ИИ Конвейер. Система должна отсекать слабые, рискованные и дублирующие инициативы раньше, чем они начнут потреблять ресурс.
Типовые причины:
- не подтверждена бизнес-проблема;
- нет владельца;
- эффект слишком мал;
- нет доступных данных;
- найден дубликат;
- риск безопасности или соответствия требованиям слишком высок;
- нет подходящего ИИ-продукта;
- инициатива не проходит по приоритету портфеля.
Если в настройках включено обязательное поле причины отклонения, платформа должна требовать заполнить причину перед переходом в отклонённое состояние.
Правила хорошей контрольной точки
Хорошая контрольная точка и хорошее решение на ней:
- проверяют не форму, а готовность к следующему этапу;
- имеют владельца решения;
- опираются на данные карточки, задачи и артефакты;
- могут быть проверены в платформе;
- не требуют лишнего комитета для очевидных решений;
- оставляют след в истории инициативы;
- понятны любому участнику через месяц после принятия;
- имеют явные критерии и влияют на следующий шаг.
Плохая контрольная точка и плохое решение:
- требуют документ ради документа;
- не имеют явных критериев;
- зависят от устной договорённости;
- пропускают инициативы без владельца и метрик;
- блокируют движение без понятной причины;
- принимаются устно, без причины и связи с карточкой;
- зависят только от статуса инициатора;
- не оставляют следа в системе.
Минимальная настройка в платформе
Для рабочей версии конвейера достаточно настроить:
- допустимые переходы бизнес-воронки;
- обязательные поля для этапов «Оценка», «Деливери» и «Ожидает эффекта»;
- правило выбора продукта перед деливери;
- правило обязательной проверки похожих инициатив;
- правило причины отклонения;
- видимость полей по этапам;
- продуктовые деливери-треки для ключевых ИИ-продуктов;
- перечень ролей, которые могут менять этап инициативы.
Такой минимум уже превращает реестр идей в управляемый механизм отбора, деливери и подтверждения эффекта.