Третий лишний: кому ИИ добавит работы, а кого оставит без заказов?

Бизнес ставит задачу. ИТ уточняет требования. Аналитик переводит для разработчиков. Теперь к каждому посадили AI и ждут, что всё наконец поедет быстрее.

А почему все решили, что сама конструкция должна сохраниться?

4 октября на «Стачке» я выступал с докладом «Третий лишний: бизнес, ИТ и AI».

Настоящая проблема AI-native трансформации не в том, какую профессию завтра заменят агенты.

Ключевой вопрос в другом: Зачем сохранять отдельный «аппендикс» кэптивного ИТ — внутреннюю фабрику заказной разработки — как обязательного посредника, если часть цифрового исполнения бизнес может получать напрямую? На каждом переходе он теряет не только деньги, но и время: объяснение, согласование, очередь, передача следующему исполнителю. Какие из этих переходов действительно нужны для результата?

Но сначала придётся разобраться с неприятной правдой. Модель знает много. Но при этом конкретный бизнес она знать не может. Или может?

Между задачей и кодом появляется новое знание

Есть удобная картинка: наверху придумали, что нужно бизнесу, дальше специалисты последовательно перевели замысел в требования, архитектуру и код. Значит, достаточно автоматизировать перевод — и можно убрать посредников.

Картинка врёт. На каждом слое добавляется знание, которого выше не было.

Человек, работающий с клиентом, знает исключение из общего правила. Аналитик обнаруживает, что два отдела одним словом называют разные вещи. Разработчик знает особенность старой системы. Специалист по эксплуатации — условия, при которых всё это действительно работает, а не только проходит демонстрацию.

Это не только испорченный телефон, который достаточно заменить хорошим проводом. Люди по дороге достраивают содержание задачи. Иногда осознанно, иногда не приходя в сознание — потому что «ну это же очевидно».

Кому очевидно? Начальнику, который сформулировал цель? Следующему исполнителю? Агенту?

Общие знания у модели есть. Как обычно устроен счёт, как написать запрос к базе, как реализовать типовой процесс. А почему именно в вашей компании этот счёт нельзя обработать обычным способом — в модели не записано. Вчерашнее решение вашего коллеги тоже не появилось там по факту принятия.

Агент всегда использует то, что знает: общие знания модели и доступный ему контекст конкретной задачи.[1] Но вчерашнее решение вашей компании не становится его знанием само собой. Если существенной конкретики нет, общее решение может выглядеть разумно — и не подходить вам. Справедливости ради, люди тоже так делают: вчерашнее «очевидно» сегодня оказывается просто галлюцинацией.

Не всякая ошибка агента объясняется отсутствием контекста. Но называть любую такую неудачу «тупой моделью» очень удобно: можно не замечать, что нужную информацию ей никто не передал.

Контекст — не свалка документов

Тогда давайте загрузим агенту всю корпоративную документацию?

Можно. Заодно передадим три несовместимые инструкции, отменённое решение и презентацию, в которой желаемое состояние бизнеса названо текущим. Теперь у нас не просто бардак. У нас бардак с быстрым исполнителем.

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

Изменили правило — какие процессы оно затронуло? Какие проверки теперь неверны? Где осталось старое описание? Если эти связи удерживаются только в голове опытного сотрудника, агент не получит их от доступа к папке.

Нужна работа с устройством знаний: откуда берётся каждый существенный факт, к чему относится, чем подтверждён, когда пересматривается. Нудно? Да. Особенно на фоне обещания «просто напишите хороший промпт».

И ещё одна неприятность. После исполнения контекст нужно обновлять.

Агент подготовил изменение, вы его применили. Что получилось? Клиенту стало проще? Ошибок стало меньше? Люди нашли новый обходной путь? Если данные об этом остались снаружи, следующая попытка начинается без знания последствий предыдущей.

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

Это связь двух ключевых вещей: локального знания и актуального контекста и обратной связи от исполнения. Доступ к папке не заменяет ни одну из них.

Агент ловит противоречие. В том числе моё

На «Стачке» я разбирал собственный пример — подготовку этого доклада с Владом. Мы обсудили содержание, сделали первый черновик, потом начали менять концепты и связи между ними.

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

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

И вот тут становится менее приятно, чем на пафосных демонстрациях ИИ возможностей.

Я предлагаю новую мысль, а проверка возвращает меня к старому решению и его основаниям. Приходится разбираться: обстоятельства действительно изменились? Я нашёл более сильное объяснение? Или просто увлёкся свежей идеей и забыл, почему раньше решил иначе?

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

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

Ускорить старую организацию или изменить её?

Теперь вернёмся к бизнесу и ИТ.

Первый вариант вполне понятен. Сохраняем существующую организацию: заказчик, требования, очередь разработки, поставка, работа кода и людей. Агентами ускоряем отдельные работы. Это может быть полезно. Не всякой компании прямо сейчас нужна реорганизация.

Но называть любое ускорение разработки с помощью ИИ AI-трансформацией — щедрый подарок собственному самолюбию. Пока мы, возможно, быстрее обслуживаем устаревшую, и не только морально, бизнес-модель. А конкуренты могут менять сам способ исполнения.

Второй начинается там, где бизнес способен поддерживать знание о своей работе, а агенты — использовать его для выполнения операций. Меняется сам носитель исполнения. Как в производстве: от кузнеца с молотом — к оборудованию, которое выполняет операции без постоянного участия человека. Проектирование, настройка, обслуживание и контроль не исчезают. Они становятся условием такого исполнения, а не каждой операцией в нём.

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

Ромб — не новая картинка оргструктуры

Здесь и появляется ромб вместо треугольника. Это профиль затрат, а не рисунок плоской оргструктуры. Если операционное исполнение переходит от людей к агентам и становится существенно дешевле, основание работы сохраняется. Но основные человеческие затраты смещаются в середину — туда, где проектируют и ведут изменения. В смешанном бизнесе разные контуры могут иметь разный профиль.

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

Схема изменения цепочки. Прежде: «бизнес → постановка → очередь ИТ → разработка → применение → результат». Возможный новый путь: «владелец процесса с актуальным контекстом → агентное исполнение в общей среде → проверка и применение → результат». Данные о результате возвращаются к владельцу и в контекст. Согласования по реальному риску сохраняются; схема не обещает убрать их все.

Операционная работа — не абстракция

Это началось не с нынешних генеративных моделей. В 2017 году Fukoku Mutual Life объявила внедрение Watson для обработки медицинских документов и подготовки расчётов страховых выплат вместе с сокращением 34 сотрудников. Финальное утверждение выплат оставалось человеку. Новость описывала объявленное изменение и ожидаемую экономию, а не подтверждённые итоги внедрения.

Этот пример показывает перенос части информационной обработки к системе. Он не доказывает автономность всего процесса или универсальную экономию. Но позволяет поставить предметный вопрос: какие операции теперь действительно требуют отдельного человеческого исполнения и его координации?

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

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

Меньше посредничества — больше задач у внутреннего ИТ

Заказная фабрика может терять роль, а задачи внутреннего ИТ при этом расширяются. Создание общей среды исполнения, о котором шла речь в докладе, — это модели, данные, доступы, инструменты, интеграции, обвязка исполнения агентов, наблюдаемость и безопасность. Кто-то должен обеспечить её надёжную работу и сопровождение.

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

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

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

Нужны люди, которые умеют разбираться в бизнесе, проектировать системы, организовывать данные и проверки. Нужна среда исполнения агентов и программ: инфраструктура, доступы, надёжность. Только всё труднее обосновывать отдельную организационную сторону тем, что она одна умеет превращать описание в код.

Людям остаётся работа с изменениями — то, что часто называют change. Решать, что менять и зачем, проверять последствия, пересматривать основания. Отвечать за результат, а не за количество переданных дальше документов.

Причём бизнесу тоже не получится отсидеться в роли заказчика. «Мы объяснили, пусть ИТ разбирается» плохо работает, когда недостающее знание находится именно у вас.

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

Как начать?

Начните с процесса, который вы хорошо понимаете.

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

Выберите метрику, по которой заметите изменение: например, время до решения задачи клиента. Зафиксируйте текущее состояние и организуйте обратную связь — откуда будут приходить данные после вмешательства и как они повлияют на следующую попытку.

А затем спросите: что должен знать агент, чтобы получить нужный результат?

Не только «какую роль написать ему в промпте».

• Какие правила действуют?
• Какие исключения существенны?
• Что нельзя сломать?
• На каких данных основано решение?
• Что из этого записано, что устарело, а что знает только человек, который сейчас в отпуске?

Для этой работы мне помогает немного трансформированное понимание знания: какая информация нужна исполнителю, чтобы получить нужный результат. Тогда управление изменениями становится в том числе управлением изменениями знаний. Мы проверили предположение на практике, увидели последствия — и поправили то, на основании чего действуем.

А затем разберите саму цепочку. Где исполнение операций, а где решения об изменениях? Какие передачи, согласования и очереди после автоматизации действительно можно убрать? Какую среду должно обеспечить внутреннее ИТ?

Если учесть стоимость этой среды, перехода и проверки, как изменятся время, качество и полная стоимость результата? Или мы просто ускорим прежнюю цепочку?

Общая модель доступна и вашим конкурентам. А знание о том, как именно работает ваш бизнес и что происходит после ваших решений, ещё нужно добыть и поддерживать. Готовый агент его в коробке не принесёт.

Возьмите свой последний опыт работы с AI. Какого конкретного знания ему не хватило — и удалось ли вам устроить работу так, чтобы в следующий раз оно уже было доступно?

Концепции и материалы

Ключевые концепции этой статьи: ромб затрат объясняет экономический сдвиг, локальное знание — условие исполнения, среда внутреннего ИТ — его технологическую основу, а обратная связь — обновление оснований следующего действия.

• Фрагмент выступления: знания и управление изменениями, 1:55.
• Полная запись зала Green 8 на «Стачке». Выступление «Третий лишний» — ориентировочно 00:26:00–01:08:14, включая вопросы; это запись всего зала, а не отдельного доклада.
• Страница записей конференции.
• Model Driven Engineering: когда модель работает, а не украшает документацию.

Примечание [1]. Агент может запросить уточнение, обратиться к доступному источнику или остановиться при нехватке данных. Это зависит от организации работы и доступных инструментов; возможность спросить не гарантирует, что пробел будет замечен.