Проблема: AI ускорял действия, но не менял процесс

Лицензия на модель помогает быстрее написать текст, подготовить заметки или разобрать документ. Но очередь согласований, возвраты RFC и потеря контекста между Jira, встречами и документацией остаются прежними.

Для бизнеса важен не объём сгенерированных материалов, а изменение времени решения, доли повторной работы, Lead Time и стоимости ошибки.

Где появился практический сценарий

Pulsar уже собирал delivery-данные через ETL, PostgreSQL и Metabase. Это создало основу для AI-сценариев: данные, определения метрик и повторяемый управленческий ритм существовали до подключения LLM.

Мы выделили четыре типа работы, где агент может готовить проверяемый результат:

  1. проверять RFC до входа в разработку — искать отсутствующий эффект, зависимости и противоречия;
  2. собирать дайджест delivery-рисков по Aging, блокировкам и выходу за P85;
  3. связывать контекст из Jira, встреч, документации и метрик перед решением;
  4. замечать расхождения между бизнес-требованием, дизайном и реализацией.

Agent-centric контур

Процесс разделён по ответственности:

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

Такой подход не создаёт «руководителя-бота». Он уменьшает механическую работу вокруг решения, не передавая модели право выбирать приоритет или принимать бизнес-риск.

Что пришлось сделать явным

AI быстро показал цену информационного хаоса. Для рабочего сценария понадобились:

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

Фраза «сотрудники пользуются AI» не стала метрикой успеха. Для каждого сценария выбирается процессный показатель: время до решения, доля возвратов, объём ручной проверки, Lead Time или стоимость ошибки.

Результат и границы кейса

Pulsar свёл данные более 20 команд в общий управленческий контур. Руководитель получает агрегированную картину за 1–2 часа вместо множества сообщений и уточнений. LLM-анализ остаётся экспериментальным слоем: его ценность проверяется по влиянию на конкретный процесс, а не по качеству демонстрации.

Этот кейс не утверждает, что AI сам сократил RFC System Lead Time. Он показывает более важное условие: организационный эффект появляется только там, где данные, критерии и точка человеческого решения уже спроектированы.

Влияние на бизнес

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

Что проверять перед AI-пилотом

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

Delivery-диагностика помогает выбрать один AI-сценарий, который можно проверить на реальном потоке, не начиная с большой AI-стратегии.