Модель A³: как связать постановку задачи, принятие решений и организационные изменения

ИИ‑проект можно технически завершить успешно и всё равно не получить бизнес‑результата.

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

Технически ИИ внедрён. Работа компании не изменилась.

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

В 2026 году Макс Чан, CIO компании Avnet, предложил A³ — управленческий фреймворк для переосмысления роли CIO в эпоху ИИ: Architect, Augment, Amplify. В этой статье я рассматриваю его подход через призму собственного опыта управления корпоративными ИТ.

A³ пока нельзя считать сложившейся методологией: у фреймворка нет обязательного набора артефактов, критериев зрелости и большого корпуса независимо подтверждённых внедрений. Но A³ возник из практики успешных корпоративных проектов: цифровые инициативы Avnet два года подряд отмечались премией CIO 100 (2025 г, 2026 г). Поэтому на этот фреймворк стоит обратить внимание.

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

Architect: сначала спроектировать само изменение

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

Architect требует начать не с технологии, а с изменения бизнеса.

В нашем кейсе предприятие хочет использовать ИИ для предиктивного обслуживания критического оборудования. Модель должна заранее оценивать вероятность отказа.

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

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

продолжить эксплуатацию;
снизить нагрузку;
провести внеплановую диагностику;
остановить оборудование.

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

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

Например:

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

Значения 20% и 12 месяцев здесь условны. В реальном проекте они должны определяться на основании статистики отказов, стоимости простоев, качества исходных данных и результатов пилота. Отдельно придётся зафиксировать критерии критического риска и правила подтверждения прогноза.

После этого меняется и постановка задачи.

Не «внедрить модель прогнозирования отказов», а:

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

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

Augment: определить место ИИ в решении

На этапе Architect предприятие уже определило, что должно измениться. Теперь возникает следующий вопрос: какое место в этом решении займёт ИИ?

Одна и та же модель может использоваться по‑разному. Она может:

только информировать о риске;
рекомендовать конкретное действие;
ограничивать продолжение операции без дополнительного подтверждения;
самостоятельно инициировать действие.

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

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

Для проектирования этого уровня Макс Чан предлагает цикл AIR:

Align — связать ИИ с конкретным решением и бизнес‑результатом;
Institutionalize — встроить рекомендацию в процессы, полномочия и контроль;
Refine — совершенствовать всю систему решения по результатам эксплуатации.

Align: связать сигнал с действием

Align отвечает не на вопрос «что умеет модель», а на вопрос «что изменится после её сигнала».

В нашем случае модель не просто показывает вероятность отказа. Её сигнал должен запускать конкретную последовательность действий:

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

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

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

Institutionalize: встроить ИИ в полномочия и ответственность

Рекомендация должна занять место в реальном процессе.

Недостаточно вывести сигнал в отдельный интерфейс или отправить уведомление. Необходимо определить:

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

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

Institutionalize означает встроить алгоритм не только в ИТ‑ландшафт, но и в систему полномочий.

На этом этапе особенно важен вопрос ответственности.

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

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

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

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

Поэтому на этапе Institutionalize недостаточно описать саму модель и её рекомендации. Необходимо зафиксировать архитектуру решения: роли, полномочия, ответственность, порядок переопределения, эскалацию и след аудита.

Прикладная схема архитектуры решения с участием ИИ. Она объединяет результат Align, требования Institutionalize и метрику, необходимую для последующего Refine.

Refine: развивать всю систему решения

После запуска совершенствовать приходится не только модель.

В нашем кейсе предприятие должно контролировать:

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

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

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

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

AIR переводит разговор с «внедрим ИИ» на «спроектируем и будем развивать решение с участием ИИ».

Amplify: превратить пилот в регулярную практику

Пилот не становится частью бизнеса только потому, что доказал эффект.

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

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

Для Amplify используется модель ARC:

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

Adapt: изменить операционную модель

Предположим, пилот подтвердил, что модель помогает сокращать внеплановый простой.

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

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

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

Это и есть Adapt.

Rewire: согласовать полномочия и стимулы

Даже точная модель не изменит поведение, если система управления поощряет обратное.

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

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

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

В нашем кейсе это может означать:

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

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

Cultivate: подготовить людей к новой системе решений

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

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

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

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

Иначе оно сохранит статус эксперимента, хотя бизнес уже начнёт от него зависеть.

Бессрочный эксперимент, от которого зависит бизнес, — это не инновация. Это бесхозная информационная система.

Что происходит, если пропустить один из уровней

В адаптированной логике A³ каждый уровень закрывает отдельный разрыв между технологией и бизнес‑результатом.

Architect без Augment оставляет неясным место технологии в решении. Augment без Architect может улучшить выбор внутри неправильно устроенного процесса. Без Amplify даже полезное решение остаётся зависимым от нескольких энтузиастов.

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

Как использовать A³ на практике

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

Для рассматриваемого в статье примера я перевёл логику A³ в диагностический чек‑лист, позволяющий проверить, целостно ли спроектировано изменение.

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

В этом и заключается прикладная ценность A³. Модель не заменяет бизнес‑кейс, архитектурное решение или план внедрения, но помогает проверить связь между ними и вовремя увидеть участок, на котором AI‑инициатива рискует остановиться.

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

Пока меняется только система, компания продолжает работать по‑старому.

Как превратить пилот ИИ в рабочий бизнес‑процесс