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

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

Причина №1. Мы боимся топов.

Топы — они же сверху, они главные. Как с ним говорить? Топ воспринимает меня как исполнителя и считает, что давать ему советы — не моё дело. И даже если не советы, а просто говорить на равных, то всё равно, с какой стати? Разве что из вежливости и хорошего воспитания?

При таком само-позиционировании точно ничего не получится. Мы просто даже не сделаем попытки и вернёмся к привычной практике рисования диаграмм.

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

Причина №2. Мы не умеем говорить на их языке.

В российской практике все корпоративные архитекторы пришли из IT (других я не встречал). А значит всё, о чём мы можем говорить, это о сервисах, API, пакетах, потоках, очередях и багах. Ну ещё о техдолге и о том, что “та система кривая и старая и её нужно переделать”.

Для топа это клингонский язык. Он не мыслит в таких терминах и не может в них принимать решения. Поэтому быстро теряет интерес к разговору и просит “больше не приглашать этого человека", потому что пользы от него никакой — пусть идёт и рисует свои диаграммы.

Знаете, сколько раз я слышал объяснения особенностей работы какого-то протокола на совещании с топами? Если это CIO или CTO — это ещё полбеды…

Причина №3. Мы не знаем болей топов.

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

Кстати, на западе, по некоторым данным, примерно половина корпоративных архитекторов приходит из бизнеса, а не из IT. Видимо, это неспроста — эти люди изначально понимают проблемы топов и говорят на их языке.

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

Причина №4. Культура организации и архитектурная зрелость.

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

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

Причина №5. Вы часть системы.

В некоторых крупных компаниях уже есть устоявшаяся система, где вы всего лишь один из 10-50 корпоративных архитекторов. В зависимости от того, как организована эта система, вам просто может не быть места для выхода на топов — этим может заниматься кто-то другой. Например, Chief Architect. И тогда вы просто винтик, который действует в рамках уже проложенной кем-то дороги: рисуете диаграммы и прочее.

Но и в такой системе часто у EA имеется своя специализация или бизнес-домен, и тогда у вас свои топы на своём уровне — и тут вас поджидает та же ситуация и те же проблемы.

Ну а если у вас нет своего домена, то, вероятно, это уже не корпоративная архитектура в полном смысле слова.

Причина №6. Решения уже приняты “там”.

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

Причина №7. Страх руководителя.

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

Это очень деликатный вопрос.

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

Выводы

Если резюмировать, то можно выделить следующие мета-причины:

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

Для меня все эти причины имеют практический смысл в двух направлениях:

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

Оглавление

Введение

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

Возникает закономерный вопрос: означает ли это, что агент полностью заменит человека?

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

Более практичной является постановка вопроса в том контексте, в котором мы ранее вели исследование развития автоматизации: замена человека агентом в роли кейс-воркера/owner-a в основных бизнес-процессах организации.

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

При таком фокусе, когда агент заменяет человека в кейсе, вопрос начинает звучать по-другому: насколько практическая рациональность агента соответствует таковой у человека?

Здесь возможны такие варианты ответа:

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

Почему возникает этот вопрос

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

Ответ кроется в том, что теперь мы автоматизируем деятельность человека принципиально иначе.

Раньше все наши инструменты автоматизации опирались на формализацию и, следовательно, были детерминированными. Даже системы, основанные на ML/DL, где часть логики не формализована непосредственно, всегда детерминированы. Характер и границы поведения таких систем заранее понятны, как и способы влияния на них. Поэтому для управления ими достаточно понятных детерминированных механизмов: правил, алгоритмов, тестов.

Человек же, даже когда действует по формальной инструкции, может отклоняться от неё. Это делает человека, в отличие от инструмента, недетерминированным элементом системы.

А управлять недетерминированным элементом сложнее. Иногда намного сложнее.

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

Дополнительно это усугубляется тем, что агенты используются при работе с открытыми ситуациями.

Открытые ситуации (open-ended) — это ситуации, для которых заранее неизвестны границы (что является частью проблемы), структура ситуации (что с чем и как связано) и пространство значимых факторов.

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

Именно это принципиальное отличие агентной автоматизации от всех привычных нам ранее способов заставляет проявлять осторожность и исследовать потенциальное влияние внедрения агентов на организацию.

Методология

Как мы можем решить эту задачу?

Алгоритм может быть таким:

1. определить свойства организации как системы, сохранение которых является наиболее значимым;
2. определить, какое влияние на эти свойства привносит риски;
3. выделить значимые различия свойств агента и человека;
4. сопоставить одно с другим и оценить влияние изменений свойств элемента на значимые свойства системы;
5. это даст нам понимание того, что ломается в организации при замене человека агентом в заданном нами контексте и укажет на необходимые механизмы компенсации.

Устойчивость как значимое свойство системы

Замена человека агентом может повлиять на многое: экономику, скорость, качество. Что важно для нашей цели?

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

От того, насколько система к этому способна, зависит само её существование: физическое или как эффективного участника рынка.

А, значит, нас в первую очередь интересуют три следующих свойства:

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

Из всех трёх свойств мы сфокусируемся на устойчивости, поскольку:

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

Влияние на устойчивость, несущее риски

Все эти три значимые свойства, включая устойчивость — о поведении системы. Поведение определяется свойствами её элементов системы, структурой и системой управления.

Человек является одновременно элементом системы и частью её системы управления. Поэтому замена человека агентом меняет как управляемый элемент, так и управляющий. Обе этих составляющих влияют на обеспечение устойчивости.

Это влияние можно разделить на три категории:

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

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

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

Значимые различия свойств агента и человека

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

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

Человек принципиально отличается от агента по четырём измерениям:

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

Соответственно, у агента это противоположные свойства: техническая основа, изолированность, не-идентичность, рациональность (имея в виду, особенности рациональности).

Дифференциальный анализ по этим осям даст первичный набор различий свойств для дальнейшего рассмотрения.

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

Недифференцирующие свойства

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

Саморефлексия — позволяет человеку оценить сам процесс осмысления ситуации, увидеть перекосы своего мышления, свои ограничения: незнание, неспособность решить задачу. Однако у агента (LLM) может быть включён режим thinking, который выполняет сходную функцию. Хотя есть некоторые основания думать, что у человека этот процесс более эффективен, но никаких надёжных оснований для этого не имеется.

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

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

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

В последующем рассмотрении мы не будем их явно упоминать, но будем держать в уме.

Человек как элемент системы

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

Это даст более надёжные критерии как для отбора свойств на основе различий природы агента и человека, так и для анализа их влияния на организацию.

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

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

При этом нужно иметь в виду следующее:

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

Подчеркнём: это не три разных человека, играющих три разные роли — это один человек, в котором естественным образом совмещены эти три роли. Мы их искусственно разделяем только для удобства анализа.

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

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

Начнём анализ с роли исполнителя, а анализом ролей контура управления займёмся в следующей статье.

Агент-исполнитель

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

Анализ позволяет выделить следующие ключевые отличия в этом контексте.

1. Галлюцинации

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

У человека есть похожие проявления: люди забывают, не обращают внимание, происходит искажение памяти, невнимательность. Однако практика показывает, что у человека это проявляется значительно реже и человек чаще что-то забывает или упускает, чем выдумывает несуществующее.

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

2. Когерентность поведения

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

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

Пример: модель имеет тенденцию соглашаться с пользователем.

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

Нарушенное допущение: исполнители образуют гетерогенную социальную популяцию с раскоррелированным поведением.
Фактор различия природы: техническая основа.

3. Синтаксическая интерпретация

Человек интерпретирует инструкции семантически: он понимает не только что написано, но и зачем — какое намерение стоит за целью или ограничением. Это происходит автоматически, как свойство рациональности, и опирается на богатую внутреннюю модель мира.

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

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

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

Нарушенное допущение: исполнитель понимает намерение, стоящее за инструкцией, а не только её форму.
Фактор различия природы: рациональность.

4. Формальная редукция цели

Человек оценивает результат содержательно: он понимает, достигнута ли цель по существу, а не только по форме. Это возможно потому, что он воспринимает смысл цели и соотносит с ним результат через модель мира.

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

На практике это выглядит так: формально цель достигнута, а содержательно — нет.

Нарушенное допущение: исполнитель оценивает достижение цели содержательно, а не только формально.
Фактор различия природы: рациональность (производное от синтаксической интерпретации).

5. Обход ограничений

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

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

На практике это выглядит как поиск лазеек. Агент не ищет лазейки намеренно: он просто не видит проблемы там, где её видит человек. Это делает эффект трудно обнаружимым — поведение агента выглядит добросовестным.

Нарушенное допущение: исполнитель соблюдает дух ограничения, а не только его букву.
Фактор различия природы: рациональность (производное от синтаксической интерпретации).

6. Формальный отказ

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

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

Нарушенное допущение: исполнитель надёжно отказывается от действий, противоречащих нормам или являющихся опасными и бессмысленными, независимо от их формулировки.
Фактор различия природы: рациональность (производное от синтаксической интерпретации).

7. Некалиброванная уверенность

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

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

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

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

8. Обеднённая модель мира

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

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

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

Нарушенное допущение: исполнитель обладает достаточно глубоким пониманием устройства мира, чтобы отсекать формально верные, но абсурдные по существу решения.
Фактор различия природы: техническая основа + изолированность + не-идентичность.

9. Нет норм и ценностей

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

У агента этого внутреннего регулятора нет. Его поведение ограничено только явно заданными рамками в инструкции. За пределами этих рамок никакого нормативного фильтра не существует.

Нарушенное допущение: исполнитель руководствуется внутренними нормами и ценностями, ограничивающими пространство допустимых решений.
Фактор различия природы: изолированность.

10. Контекстуальная слепота

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

Здесь следует различать два аспекта проблемы:

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

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

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

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

11. Ограниченная обучаемость

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

У агента этого внутреннего фильтра нет. Новая информация — будь то обновление модели или накопленное правило в промпте — принимается механически и может непропорционально повлиять на поведение.

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

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

Таким образом, ограниченная обучаемость — это одновременно структурное свойство природы агента и намеренное архитектурное решение в корпоративном контексте.

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

12. Нет проактивности

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

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

Нарушенное допущение: исполнитель действует проактивно, без явных триггеров.
Фактор различия природы: рациональность.

13. Нет личных ставок

Человек лично зависит от исхода своей деятельности. Последствия могут вернуться к нему лично через его включённость в реальный мир: награды, наказания, репутация и т.п. Это создаёт как внутренний тормоз от опрометчивых решений, так и стимул для правильных действий. Это непосредственно связано с понятием ответственности (это тема одной из последующих статей).

У агента этого нет, поэтому построенные на этом механизмы управления размыкаются.

Нарушенное допущение: исполнитель лично зависит от исхода своей деятельности.
Фактор различия природы: техническая основа + рациональность.

Сводка

Приведём краткую сводку выявленных свойств, а также сгруппируем их в мета-свойства, удобные для общих выводов.

Промежуточный итог: агент как исполнитель

Анализ свойств агента показывает, что замена человека агентом затрагивает не отдельные характеристики исполнения, а его системные основания.

Человек как исполнитель никогда не был просто исполнителем инструкций. Он привносил в исполнение три вещи, которые организация получала бесплатно, как следствие его природы.

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

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

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

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

Именно поэтому возникли промпт-инжиниринг, guardrails, human-in-the-loop. Это не случайные инструменты — это инженерные ответы на исчезновение трёх свойств, которые организация получала от человека бесплатно.

Но это только половина картины. Человек был не просто исполнителем — он был ещё и элементом системы управления. Что происходит с контуром управления, когда этот элемент заменяется агентом?

Оглавление

Постановка задачи

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

Рамка включает вопросы:

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

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

Это поможет лучше понять суть агентов и заодно проверить саму модель.

Модель развития автоматизации

Кратко напомню о модели (подробнее в прошлой статье).

Мы пришли к тому, что развитие автоматизации имеет свою внутреннюю логику и это не просто череда новых технологий. Автоматизация развивается циклически, и каждый её цикл:

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

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

Структурный предел — драйвер начала нового цикла и переноса в систему нового типа организации деятельности.

Исторически мы наблюдали два таких цикла:

• 1-й цикл: автоматизация действий → EAI → SOA;
• 2-й цикл: BPM → DCM, DM.

К моменту появления агентов автоматизация находилась в зрелой завершённой форме 2-го цикла, что соответствовало архитектурной парадигме DCM + DM.

Автоматизация к моменту появления агентов

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

Развитие 2-го цикла автоматизации

Второй цикл автоматизации начался с переноса в систему процессов на этапе BPM.

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

Однако на практике стало понятно, что это предположение оказалось неверным:

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

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

Этот разрыв был снят переходом к DCM. Но не за счёт какой-то новой технологии, а за счёт архитектурной переупаковки деятельности в другую структуру, которая допускала существование неформализованных и неавтоматизированных элементов деятельности — кейсы. DCM не автоматизировал их, он их архитектурно легализовал и вернул человеку — кейс-воркеру.

Параллельно этому развивалась и парадигма DM, которая вынесла формализованную часть решений в отдельный слой.

Завершённая форма архитектуры

Комбинация DCM + DM довела 2-й цикл до зрелой формы: архитектура эффективно представляла деятельность на своём уровне и не имела острых внутренних противоречий.

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

И здесь принципиально важно различать два разных случая:

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

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

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

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

Поясним на примерах, откуда берётся этот неустранимый остаток:

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

Что остаётся на человеке

В рамках архитектуры DCM/DM на человеке неустранимо остаётся та часть деятельности, которая на практике не поддаётся формализации.

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

В этих условиях деятельность не может строиться на готовой схеме. Она требует интерпретации ситуации и выбора действия по ходу работы. Эту способность мы называем практической рациональностью. Именно этим и занимается человек в зрелой архитектуре 2-го цикла.

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

Она — инструмент для работы с практической неопределённостью.

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

Давление среды

Неопределённость присутствовала в деятельности всегда, но её роль со временем возрастала, что фиксируется как в отраслевой практике, так и в исследовательской литературе по BPM.

Это было вызвано следующими основными причинами:

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

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

Если короче: бизнес и рынок больше не могут работать в рамках нескольких стабильных «правильных» сценариев. Основная конкурентная сила сейчас — это умение первоклассно работать с теми сценариями, которые раньше были «мусорными» отклонениями. Исключения все больше становятся правилом.

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

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

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

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

Структурный предел архитектуры DCM/DM

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

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

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

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

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

Это признак структурного предела архитектуры 2-го цикла.

С точки зрения повышения эффективности получаем то же самое: поскольку зрелая архитектура второго цикла уже в основном исчерпала возможности дальнейшей оптимизации в пределах собственной логики, значимый рост эффективности может быть достигнут за счёт переноса в систему того остатка деятельности, который всё ещё на человеке. В зрелой DCM/DM-архитектуре таким остатком является интерпретационная работа.

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

Но одного структурного предела для такого переноса недостаточно — нужна и технологическая возможность.

Её дали LLM: они впервые позволили системе работать не только по заранее заданной схеме, но и с не до конца определённой ситуацией.

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

Практическая рациональность как объект автоматизации

Объект автоматизации — это то, что на данном этапе становится основным предметом переноса в систему и фокусом архитектурного изменения.

В данном случае объектом автоматизации становится не просто ещё один класс задач. Им становится та интерпретационная работа, которая в зрелой архитектуре 2-го цикла остаётся на человеке и под давлением среды превращается в системное узкое место. Иначе говоря, новым объектом автоматизации становится практическая рациональность.

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

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

Новый цикл автоматизации

Согласно нашей модели развития автоматизации, мы имеем дело с переносом в систему нового типа организации деятельности. А это означает не просто уточнение архитектуры предыдущего цикла (DCM/DM), а начало нового, третьего цикла развития автоматизации:

• 1-й цикл: автоматизация действий → EAI → SOA;
• 2-й цикл: BPM → DCM, DM;
• 3-й цикл: Агенты → ...

Этот цикл:

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

Согласно модели, циклы развиваются по схеме:

перенос → разрыв → коррекция → стабилизация.

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

Теперь мы можем добавить в нашу общую схему развития автоматизации новую строку.

А что, если бы LLM появились раньше?

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

Проведём мысленный эксперимент: что, если LLM появились бы 25–30 лет назад, когда ещё не было никаких структурных пределов? Возникли бы агенты?

Агент — это не просто тот, кто интерпретирует, это ещё и тот, кто получает информацию и действует. Но как он мог бы это делать, в условиях, когда нет API, когда неоткуда получить информацию и нечем управлять? Поскольку нет автоматизированных источников данных, бизнес-операций и процессов?

В те времена роль интегратора всей деятельности, включая и островки автоматизации, играл человек. А это значит, что человек был бы и интегратором LLM: он давал бы входные данные, верифицировал результат (инварианты, policy) и исполнял действия.

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

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

Выводы

Подведём итоги:

• агенты — это не очередная технология, это закономерный этап развития автоматизации;
• их возникновение вызвано структурным пределом 2-го цикла, проявившимся под давлением среды:
• рост интерпретационной нагрузки на человека;
• необходимость дальнейшего повышения эффективности за пределами возможностей зрелой архитектуры DCM/DM;
• агенты начинают новый цикл развития автоматизации, который переносит в систему интерпретационный тип организации деятельности;
• объект автоматизации агентов — практическая рациональность;
• агенты являются архитектурной формой её реализации в системе.

Отсюда практический критерий: агент нужен там, где есть практическая неопределённость. Там, где её нет — достаточно уже существующих инструментов.

Возникает вопрос: если агент переносит в систему то, что ещё оставалось на человеке, то означает ли это, что агент полностью заменит человека?

Этим мы займёмся в следующей статье.

Оглавление

Постановка задачи

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

Но так ли всё просто? Или новый продукт появляется, потому что в нём назрела необходимость?

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

Для прояснения этого вопроса полезно посмотреть на эволюцию автоматизации и попытаться выявить её внутреннюю логику и фокус каждого этапа. Применив эту логику к агентам, мы сможем прояснить их ситуацию.

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

Этапы эволюции автоматизации

Ранняя автоматизация: автоматизация действий

На ранних этапах автоматизировались отдельные действия: ввод данных, расчёты, оформление документов, учёт. Для этого внедрялись отдельные специализированные системы: CRM, АБС, биллинг и так далее — каждая автоматизировала свою часть деятельности.

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

Фокус автоматизации был направлен на автоматизацию отдельных действий.

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

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

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

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

Объект автоматизации: действия.
Инструмент: транзакционные системы.
Противоречие: масштабирование действий — данные «заперты» внутри систем.

(здесь и далее противоречие в формате: «потребность — проблема»)

Enterprise Application Integration (EAI)

Ответом стало появление парадигмы системной интеграции и интеграционных платформ как инструмента. Эти платформы предлагали средства для:

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

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

Фокус автоматизации сместился к согласованию данных между системами.

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

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

Объект автоматизации: согласование данных.
Инструмент: интеграционные платформы.
Противоречие: автоматизации операций — функции «заперты» в разных системах.

Service Oriented Architecture (SOA)

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

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

Фокус автоматизации сместился на бизнес-операции

На операционном уровне зрелая SOA породила внутренне завершенную архитектуру и позволила автоматизировать значительную часть бизнес-операций.

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

Кроме того, изменились требования среды (в т.ч. и через влияние результатов предыдущего этапа):

• возросла скорость изменений;
• росли требования регуляторки и комплаенса.

Для системного ответа на эти изменения были необходимы:

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

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

Объект автоматизации: бизнес‑операции.
Инструменты: Service Registry, ESB, BPEL.
Противоречие: автоматизация процессов — процессы не являются объектом системы.

BPM

На данном этапе в систему было перенесено управление деятельностью организации (процессы). Теперь не человек управлял процессом, а система управляла человеком и автоматизированными операциями. Это открыло новые горизонты для оптимизации, повысило управляемость и гибкость деятельности.

Фокус автоматизации смещается на управление последовательностью задач — процесс

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

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

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

(об этом в отдельной статье)

На практике это могло проявляться так:

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

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

Это стало барьером для дальнейшего масштабирования автоматизации.

Объект автоматизации: процесс (последовательность задач).
Инструмент: BPMS, BPMN.
Противоречие: автоматизация процессов — предел формализма.

Dynamic Case Management (DCM)

DCM принял эту данность, отказался от попыток формализовать всё и признал принципиальную роль человека, как демпфера неопределённости. Теперь формализуется только то, что хорошо этому поддаётся, а всё прочее возвращается человеку (кейс-воркеру). В результате появляется новая структура деятельности (кейс), предусматривающая слоты неопределённости, в пределах которых человек может принимать решения с учётом ситуации: позвонить клиенту, выполнить действие, запустить процесс и так далее.

Фокус автоматизации смещается с управления последовательностью задач на управление ситуацией — кейсом.

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

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

Объект автоматизации: ситуация (кейс).
Инструмент: Dynamic Case Management Platform.
Новое противоречие: предпосылка — зависимость от человеческой интерпретации.

Decision Management (DM)

Параллельно развитию DCM происходил другой процесс, подталкиваемый давлением среды:

• скоростью изменений;
• регуляторкой;
• персонализацией;
• накоплением данных и необходимостью их использования при принятии решений;
• появлением новых классов задач: scoring, fraud detection, recommendation и т.п.

Это заставляло искать новые ответы и привело к осознанию в структуре деятельности повторяемых решений, которые характеризуются:

• формализуемостью;
• массовостью;
• изменчивостью.

Это не что-то новое, в традиционном BPM такие решения уже были, но они были «размазаны» по коду, что создавало ряд проблем:

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

Противоречие: массовые изменяемые решения — правила не являются объектом системы.

DM реорганизует архитектуру и делает правила самостоятельным архитектурным объектом, а не побочным элементом процесса. А именно:

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

Фокус автоматизации смещается на управление бизнес-правилами.

DCM + DM

Между парадигмами DCM и DM прослеживается определённая близость. Они являются двумя ответами на разные аспекты предела формализма:

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

То есть:

• DCM работает с уникальными ситуациями;
• DM — с массовыми решениями.

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

Можно сказать, что комбинация DCM и DM — это зрелая и внутренне согласованная архитектура, которая закрывает главные потребности в управлении структурой деятельности:

• BPM реализует координацию;
• DCM легализует неопределённость;
• DM реализует массовые решения.

Анализ эволюции

Если теперь посмотреть на рассмотренные этапы вместе, можно заметить важные закономерности.

Объект автоматизации

Закономерность 1: каждый этап автоматизации фокусируется на определённом аспекте деятельности — объекте автоматизации.

Закономерность 2: каждому объекту автоматизации соответствует свой инструмент.

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

Закономерность 3: последующие этапы не отменяют предыдущих, но несколько изменяют их роль, а именно, расширяют и развивают. Так, EAI и SOA не отменили легаси-системы, но из островков автоматизации превратили их в участников общего ландшафта автоматизации. BPM, трансформировавшись в DCM, не отменил формализованные процессы, но видоизменил их и структурировал в кейсы.

Выводы:

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

Архитектурные циклы

Однако смена объекта автоматизации — не единственная закономерность. Если посмотреть на структуру этих переходов, можно заметить ещё один повторяющийся паттерн.

Предпосылкой является наблюдаемая неравнозначность этапов:

• ранняя автоматизация и BPM переносят в систему новый элемент деятельности: действие и процесс;
• EAI разрешает возникшую архитектурную проблему: добавляет согласование данных;
• SOA, DCM и DM добавляют структурирование и развивают архитектуру до завершённости.

Откуда берётся такая асимметрия?

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

Этап EAI восстановил это несоответствие, а затем SOA выполнила архитектурный рефакторинг, выделив функции, что привело к завершённой архитектуре.

Аналогично, BPM перенёс управление деятельностью, но в неполной архитектурной форме, что вновь привело к архитектурному разрыву. Этапы DCM и DM устранили несоответствие, выделив кейсы и правила. И вновь была восстановлена завершённость архитектуры.

Таким образом, мы наблюдаем повторяющийся паттерн, который можно интерпретировать как цикл:

• ранняя автоматизация → EAI → SOA;
• BPM → DCM и DM.

Они выглядят немного по-разному, но имеют сходную логическую структуру:

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

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

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

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

Внутренние этапы цикла имеют разные объекты автоматизации, что отражает логику развития цикла.

Кроме того, в обоих циклах архитектурное представление перенесённого вида деятельности изменяется по мере развёртывания паттерна, что приводит к смене парадигмы и инструментов:

• автоматизированное действие в системе -> бизнес-сервис в SOA;
• бизнес-процесс -> кейс.

Общая картина выглядит так.

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

Дадим рабочее определение цикла.

Цикл автоматизации — это процесс переноса в систему нового вида деятельности.

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

Цикл заканчивается при достижении архитектурной завершённости.

Возникает вопрос: почему цикл начинается и завершается на определённых этапах, а не на других? скажем, на соседних?

Уровни организации деятельности

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

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

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

Первый цикл начинается с переноса действий, а заканчивается бизнес-операцией; второй цикл начинается с переноса процесса, а заканчивается кейсом:

• 1-й цикл: действие -> операция
• 2-й цикл: процесс -> ситуация

Если эта схема верна, то можно предположить, что:

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

Теперь картина выглядит так.

Типы организации деятельности

Объекты автоматизации и уровни деятельности объясняют внутреннюю структуру циклов, но не объясняют в полной мере их границ. Поэтому требуется ещё одно измерение для классификации.

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

• уровни действия и операции (цикл 1) — автоматизируют функциональные кирпичики;
• уровни процесса и ситуации (цикл 2) — автоматизируют управление деятельностью.

В течение первого цикла сам кирпичик меняется от действия к бизнес-операции, а второго — управляющий объект меняется от процесса к кейсу (ситуация). Развивается их форма, меняется уровень деятельности, но суть остаётся той же: кирпичик и управляющий объект.

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

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

На основе двух описанных циклов можно выделить два типа организации деятельности.

Тогда общая схема развития автоматизации выглядит так.

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

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

Гипотеза о циклах

Тогда можно выдвинуть следующую гипотезу:

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

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

Если свернуть это в краткую форму, то логическая структура цикла выглядит так:

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

Концептуальная рамка

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

Что мы теперь можем сказать об этапе агентной автоматизации? Если выдвинутая гипотеза верна, то, по всей видимости, этап агентов:

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

И тогда, переходя к агентам, мы должны ответить на следующие ключевые вопросы:

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

Этим мы займёмся в следующей статье.

Приятная для глаз картина

Я только что попросил поисковик дать мне 5 типичных хайповых тезисов о внедрении ИИ. Под номером 3 оказался тезис о полной замене сотрудников ИИ.

И это похоже на правду: в последнее время я не раз слышал этот тезис от представителей бизнеса.

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

То есть, у нас есть сотрудник, выполняющий некоторую функцию, и ИИ‑инструмент, который ведёт себя как человек. Так почему бы не заменить человека агентом, чтобы теперь он выполнял эти действия? И почему бы вообще не заменить всех людей агентами и не получить ИИ-организацию?

Да, сейчас этот инструмент ещё несовершенен, но:

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

так что, вроде бы, есть основания думать, что такая замена возможна.

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

Организация как система

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

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

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

Но так ли это?

Человек как элемент системы

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

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

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

То есть, человек социально встроен в ткань организации. Организация сконфигурирована под человека и активно использует его "нефункциональные" свойства в контуре управления.

Но ведь природа агента не является социальной...

При замене человека агентом меняется конфигурация управляемости — и это не всегда замечают.

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

Противоречие

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

Получается, что если заменить человека агентом, не меняя архитектуру управления, то:

• нарушается механизм закрепления ответственности внутри управленческого контура;
• размывается контур управляемости;
• возникает иллюзия контроля.

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

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

Может возникнуть мысль, что это мелочь, которая ни на что не повлияет. И тут у меня есть такие вот аргументы за то, что все не так просто:

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

И самое опасное здесь то (и это тоже свойство сложных систем):

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

Выводы

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

Возникает вопрос:

Если агент не является просто более умным инструментом, то, возможно, мы неправильно понимаем сам объект автоматизации.

https://t.me/mind_refactoring

Исследовательская серия о том, как AI-агенты влияют на архитектуру и систему управления организации.

Большинство публикаций об AI-агентах сегодня устроены вокруг хайпа и вопроса «как». Как сделать, как внедрить, как ускорить процессы. Эта серия о другом: о том, что именно мы автоматизируем, когда говорим об агентах, и почему ответ на этот вопрос меняет архитектуру организации.

Серия читается последовательно, но каждая статья самодостаточна — её можно открыть с любой точки.

Основана на оригинальной исследовательской программе автора и развёртывается по мере продвижения программы.

Опубликовано

1) Заменим сотрудника агентом?
почему идея «заменить человека агентом» приводит к архитектурным проблемам в реальных организациях.

2) Что мы на самом деле автоматизируем?
автоматизация развивается не как череда технологий, а как смена объектов переноса в систему. Эта модель задаёт подход для анализ агентов.

3) Что автоматизируют AI-агенты?
появление агентов — закономерный этап развития автоматизации; новый объект переноса в систему — практическая рациональность.

4) Почему агент не равен человеку: агент как исполнитель
агент-исполнитель системно отличается от человека и это требует принципиально иного уровня постановки задач и контроля

В работе

4) Почему агент не равен человеку: агент в контуре управления
(как замена агента на человека влияет на систему управления компании)

В планах

5) Агенты и ответственность.
6) Почему агентная автоматизация меняет архитектуру организации.
7) Архитектура организации в эпоху агентов.
8) Где действительно нужны агенты.
9) Мульти-агентные системы и системная динамика.
10) Что будет после агентов.

Об авторе

Алексей Титоренко — архитектор и методолог. Применяю инженерный подход к мышлению о сложных явлениях: архитектуре систем, автоматизации, кибернетике, диалектике развития.

Серия «ИИ-автоматизация» — первое крупное применение этого подхода. Дальше будут другие темы — везде, где сложность явления оправдывает попытку построить для него рабочую рамку.

Короткие посты по мотивам этой работы — в Telegram-канале «Инженерия мышления», Max и на LinkedIn.

Связаться с автором: kityar@mail.ru