Почему AI-пилот не становится результатом
Покупка лицензий и запуск чат-бота могут ускорить отдельную операцию, но не изменить срок или качество управленческого процесса. Эффект теряется, если результат модели живёт отдельно от регулярного решения, его приходится перепроверять вручную или никто не отвечает за реакцию на сигнал.
Поэтому начинать стоит не с выбора модели, а с процесса, который организация хочет изменить.
Выберите одно управленческое решение
Подходящий сценарий имеет повторяемый вход, понятный результат и владельца решения. В delivery это может быть:
- первичная проверка качества RFC;
- выделение рисков из статусов и встреч;
- поиск повторяющихся блокировок;
- подготовка еженедельного дайджеста;
- объяснение изменения flow-метрик;
- обнаружение инициатив без ожидаемого эффекта или владельца.
Формулировка «анализировать всё» почти всегда слишком широка для первого эксперимента.
Разделите работу модели и человека
Модель может собрать данные, классифицировать сигнал, подготовить объяснение или предложить вопросы. Человек должен сохранить решение там, где есть ответственность, неоднозначность или высокая цена ошибки.
Полезно явно описать четыре элемента:
- какие источники получает модель;
- какой результат она возвращает;
- что обязательно проверяет человек;
- какое действие происходит после подтверждения.
Так появляется управляемый процесс, а не набор случайных запросов к LLM.
Какие данные использовать
Для управленческого анализа полезны не только записи Jira. Контекст может включать цели, RFC, сообщения, встречи, календарь, историю решений и flow-метрики.
Доступ должен соответствовать задаче. Не нужно отправлять модели больше данных, чем требуется для выбранного решения. Для чувствительной информации заранее определяются допустимые источники, срок хранения и способ проверки результата.
Как измерить эффект
Метрика должна описывать изменение процесса, а не количество запросов к AI. Возможные показатели:
- время от появления сигнала до решения;
- доля RFC, прошедших проверку до старта;
- количество рисков, обнаруженных до срыва;
- время подготовки управленческого обзора;
- доля рекомендаций, подтверждённых владельцем процесса;
- изменение Lead Time или Aging после внедрения решения.
Сначала фиксируется исходное состояние. Затем AI включается на ограниченной выборке, и результат сравнивается по одному и тому же критерию.
Когда эксперимент стоит остановить
Эксперимент не следует масштабировать, если критерий качества не определён, источники ненадёжны, перепроверка дороже ручной работы или у сигнала нет владельца. Отрицательный результат полезен: он показывает, что проблема находится не в скорости анализа, а в устройстве решения.
Пример рабочего контура
В кейсе Pulsar и AI в delivery LLM-анализ использовался для первичной проверки RFC, дайджестов риска и объяснения данных. Модель подготавливала сигнал, а управленческое решение оставалось у владельца инициативы или руководителя.
На delivery-диагностике можно выбрать процесс, где AI способен изменить измеримый результат, и отделить полезную автоматизацию от демонстрационного пилота.