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

Модель контрольных точек

Назначение

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

Модель опирается на функционал платформы «ИИ Конвейер»: бизнес-воронку инициатив, продуктовые деливери-треки, настраиваемые правила переходов, обязательные поля, проверку похожих инициатив, задачи, артефакты и аналитику.

Основные идеи

  • Этап — состояние инициативы в бизнес-воронке: новая, оценка, деливери, ожидание эффекта, поддержка, закрытие или отклонение.
  • Контрольная точка — проверка перед переходом на следующий этап. Она должна быть понятной, проверяемой и заранее известной участникам.
  • Правило перехода — настройка платформы, которая определяет, из какого этапа в какой можно перейти.
  • Обязательные поля — минимальный набор данных, без которого решение нельзя считать управляемым.
  • Продуктовая воронка — этапы деливери внутри выбранного продукта ИИ. У разных продуктов эти этапы могут отличаться.
  • Решение — зафиксированный итог контрольной точки: продолжить, доработать, остановить, отклонить или перевести на поддержку.

Как это работает

Инициатива движется по бизнес-воронке:

Новая → Оценка → Деливери → Ожидает эффекта → На поддержке / Закрыта

Инициатива может быть отклонена, если ценность не подтверждается, риск слишком высок, нет данных, нет владельца или есть более приоритетные работы.

В платформе этим этапам соответствуют состояния NEW, ASSESSMENT, DELIVERY, AWAITING_EFFECT, ON_SUPPORT, CLOSED и REJECTED.

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

Детали жизненного цикла — в жизненном цикле инициативы.

flowchart LR
subgraph Контрольные точки
G1[КТ 1] --> G2[КТ 2] --> G3[КТ 3] --> G4[КТ 4] --> G5[КТ 5]
end
subgraph Этапы
S1[Новая] --> S2[Оценка] --> S3[Деливери] --> S4[Ожидает эффекта] --> S5[Поддержка или закрытие]
end
G1 -.-> S1
G2 -.-> S2
G3 -.-> S3
G4 -.-> S4
G5 -.-> S5

Карта контрольных точек

Контрольная точкаПереходГлавный вопросМинимальные критерииВладелец решения
КТ 1. Регистрацияпроблема → новая инициативаСтоит ли фиксировать идею в портфеле?Есть проблема, инициатор, краткое описание, ожидаемый тип эффектаИИ-офис или руководитель направления
КТ 2. Допуск к оценкеновая → оценкаДостаточно ли данных, чтобы разбирать инициативу?Заполнены базовые поля, понятен владелец, нет очевидного дубляИИ-офис
КТ 3. Допуск к деливериоценка → деливериИмеет ли смысл тратить команду и продуктовый ресурс?Выбран продукт, выполнена проверка похожих инициатив, безопасность не отклонила, есть гипотеза эффекта и приоритетКомитет или назначенный ответственный
КТ 4. Запуск ожидания эффектаделивери → ожидает эффектаРешение внедрено настолько, что можно измерять результат?Деливери завершена, есть владелец процесса, определены метрики, дата проверки эффекта и источник данныхВладелец инициативы вместе с ИИ-офисом
КТ 5. Завершение или поддержкаожидает эффекта → поддержка/закрытаЭффект подтверждён и понятно, что делать дальше?Рассчитан фактический эффект, есть решение о закрытии, поддержке, масштабировании или доработкеБизнес-владелец, финансы, ИИ-офис
Отклонениелюбой ранний этап → отклоненаПочему инициативу не продолжаем?Указана причина, сохранена история решения, при необходимости предложен возврат или пересмотрОтветственный за текущий этап

КТ 1. Регистрация инициативы

Цель — не доказать ценность, а зафиксировать идею так, чтобы она не потерялась и могла быть оценена.

Минимальный вход:

  • бизнес-проблема;
  • инициатор;
  • подразделение или процесс;
  • краткое описание идеи;
  • предварительный тип эффекта.

Результат:

  • создана карточка инициативы;
  • стадия установлена как «Новая»;
  • инициатива попала в портфель;
  • при необходимости создан первичный набор задач.

Что может помочь ИИ-помощник:

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

КТ 2. Допуск к оценке

Цель — отделить сырой поток идей от инициатив, которые стоит разбирать содержательно.

Минимальные критерии:

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

Решения:

  • перевести в оценку;
  • вернуть на уточнение;
  • отклонить с причиной;
  • объединить с похожей инициативой.

Платформенная опора:

  • карточка инициативы;
  • проверка похожих инициатив;
  • обязательные поля по этапу;
  • история переходов.

КТ 3. Допуск к деливери

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

Минимальные критерии:

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

В платформе переход в деливери должен блокироваться, если не выбран продукт или не выполнена обязательная проверка похожих инициатив. Если предварительная проверка безопасности имеет отрицательный результат, инициатива не должна идти в деливери без отдельного решения.

Решения:

  • допустить к деливери;
  • отправить на доработку оценки;
  • сменить продукт;
  • отложить из-за нехватки ресурсов;
  • отклонить.

КТ 4. Запуск ожидания эффекта

Цель — убедиться, что решение не просто разработано, а готово к проверке результата в бизнес-процессе.

Минимальные критерии:

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

Решения:

  • перевести в ожидание эффекта;
  • оставить в деливери на доработку;
  • перевести на поддержку без эффекта только как исключение;
  • отклонить деливери, если решение не пригодно к использованию.

Платформенная опора:

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

КТ 5. Завершение, поддержка или масштабирование

Цель — не закрыть карточку ради чистого реестра, а принять управленческое решение на основе фактического результата.

Минимальные критерии:

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

Решения:

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

Отклонение инициативы

Отклонение — это нормальный результат конвейера. Система должна отсекать слабые, рискованные и дублирующие инициативы раньше, чем они начнут потреблять ресурс.

Типовые причины:

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

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


Правила хорошей контрольной точки

Хорошая контрольная точка:

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

Плохая контрольная точка:

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

Минимальная настройка в платформе

Для рабочей версии конвейера достаточно настроить:

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

Такой минимум уже превращает реестр идей в управляемый механизм отбора, деливери и подтверждения эффекта.