Вот это важное продолжение: полномочие без механизма устаревания довольно быстро превращается в технически корректную ошибку. Причём я бы смотрела даже не столько на срок, сколько на события: сменился договор, владелец процесса, нормативный источник, порог риска - разрешение автоматически “протухло”, агент вернулся в черновик.

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

Антон, вот этот критерий мне как раз очень близок: границу автономности ИИ задаёт не столько доверие к модели, сколько цена отката. Ошибочный текст можно переписать. Отправленный платёж, изменённые данные или письмо клиенту - уже совсем другой класс последствий.

Получается, человек в контуре нужен не возле каждого движения агента, а в тех точках, где ошибка становится дорогой, труднообратимой или вообще необратимой. Это, по-моему, гораздо полезнее универсального “проверять всё”

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

Антон, явный гейт мне как раз нравится больше, чем попытка научить модель самой чувствовать границу риска. У неё с этим чувством пока своеобразные отношения.

Я бы только цену отката считала шире технической обратимости. Письмо клиенту можно отправить повторно, платёж - вернуть, данные - восстановить из резервной копии. Но репутационный, финансовый или юридический эффект иногда уже произошёл.

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

Дарья, да 🙂 Особенно узнаваемо про температуру начальства - такой интерфейс пока плохо документирован. Но я бы оставила право передумать: бизнес всё-таки живой. Вопрос скорее в том, чтобы изменение правила тоже было правилом - кто может его поменять, почему, с какого момента и что делать с уже запущенными процессами. Иначе автоматизируем не работу, а ежедневное чтение настроения руководителя

Сейчас требуется уметь в ИТшную логику. Без этого нейросети не интегрируются должным образом. А менеджмент привык больше полагаться на интуицию и творческое воображение. Это плохо сочетается с логикой ИИ, вывезти такую гуманитарную логику способны только люди)

Дарья, я бы только не стала требовать от менеджмента именно ИТ-логики. Скорее - способности различать, где правило действительно можно описать, а где начинается управленческое суждение. Интуиция, опыт, контекст, понимание людей никуда не исчезают. Но если половина процесса держится на том, что “руководитель почувствует, как правильно сегодня”, ИИ просто очень наглядно показывает, насколько этот процесс был неформализован 🙂 Получается, технология здесь не столько требует от нас стать айтишниками, сколько заставляет честнее увидеть границу между правилом и личным решением

Кристина, у вас, мне кажется, как раз довольно благодарная задача для агента: внешний ресерч можно ограничить источниками, заранее определить состав досье и потом проверить результат.

С внутренними процессами веселее 🙂 У одного показателя могут оказаться три владельца, у процесса - две официальные версии и одна реальная. Поэтому до API для меня важнее выяснить, где источник истины, кто вправе менять правила, что считается исключением и кто принимает решение, если что-то пошло не по сценарию.

И иногда на этом этапе обнаруживается, что самое эффективное улучшение процесса - пока не агент, а одна хорошо зафиксированная договорённость между людьми

Ярослав, именно 🙂 Автоматизация не умеет сама провести санитарную обработку процесса.

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

Иначе автоматизация не исправляет бардак, а просто ставит его на конвейер.

У вас аналитиков обычно подключают до автоматизации или уже когда она начала бодро масштабировать проблему?

Это лучше у аналитиков спрашивать я из разработки)

Вот здесь, по-моему, и начинается командная работа 🙂 Аналитик разбирает логику процесса, но разработка часто первой видит, где требования противоречат системе или дорого обойдутся при реализации.

Поэтому хороший результат рождается на стыке: бизнес отвечает за смысл, аналитик - за логику, разработка - за реализуемость. А у вас разработчик может вернуть задачу на пересборку, если видит, что автоматизируется бардак?

Если артефакт аналитика прошел dor то нет. В разработку просто не попадают задачи в которых чего то нет или не хватает или бардак.

Ярослав, тогда у вас хорошо выстроен барьер на входе в разработку. Но DoR подтверждает готовность задачи к реализации, а не обязательно качество самого бизнес-процесса.

Плохой процесс тоже можно полно и непротиворечиво описать. Поэтому я говорю о командной проверке не только «всего ли хватает в задаче», но и «нужно ли вообще автоматизировать это именно так».

Иначе технически корректная задача может превратиться в технически безупречную автоматизацию бардака 🙂. Спасибо за дискуссию.

Аминь, бро!

Театр. Пьеса. На сцене происходит что-то совершенно неудобоваримое. Актёры играют из рук вон плохо, сюжет говно. В середине акта в зрительном зале раздаётся истошный вопль: — ДОКТОР! ЕСТЬ ЛИ В ЗАЛЕ ДОКТОР!?! — Я доктор! Что случилось? — Коллега! Какую же х**ню нам показывают!

Вот примерно поэтому я и за командную проверку до старта: чтобы доктор нашёлся не в зрительном зале после премьеры, а ещё на репетиции 🙂

Ринат, согласна: история любит возвращаться, предварительно сменив интерфейс.

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

Так что старый бардак рискует получить не просто компьютер, а ключи от здания.