Три попытки собрать сложную организацию в один контур — ОГАС, корпоративные ERP, генеративный AI — провалились по одной причине. Что это значит для архитектуры управления холдингом сегодня.
В кабинете генерального директора на стене висит схема группы компаний. Не новая, но еще достаточно актуальная, чтобы ее не сняли. Производственная компания, торговый дом, складская структура, лаборатория, сервисное подразделение, отдельное юридическое лицо под импорт, еще одно под недвижимость и под новый проект. Линии между ними нарисованы аккуратно: владение, управление, поставки, финансы, ответственность.
На бумаге это выглядит как система.
В реальности директор каждую неделю видит другое. В одной компании работает своя 1С. В другой — другая конфигурация, доработанная еще пять лет назад под конкретного бухгалтера. Склад живет в собственных таблицах, потому что так быстрее. Отдел продаж ведет часть сделок в CRM, часть в Excel, часть — в переписке, где «и так все понятно». Банк показывает движение денег в одном интерфейсе, бухгалтерия — в другом, управленческий отчет собирается третьим способом. Логистика присылает статусы в мессенджер. Поставщик из Китая пишет в WeChat. Индийский партнер — в WhatsApp. Юрист держит последнюю версию договора у себя на диске. Коммерческий директор помнит, кто что обещал, лучше любой системы.
Формально компания оцифрована.
Практически она живет в нескольких реальностях одновременно.
И каждый раз, когда нужно принять решение, эти реальности приходится собирать вручную. Не потому, что компания отсталая. Наоборот, в ней достаточно систем, файлов, кабинетов, регламентов и ответственных людей. Проблема в другом: все это не складывается в один общий язык без участия человека, который помнит, что где лежит, кто что имел в виду, какой документ настоящий, а какой просто последний по дате.
Раньше это называлось опытом руководителя.
Теперь все чаще становится узким местом системы.
Холдинг как архитектура роста
Российский бизнес 2000-х во многом строился через холдинги. Это не было модой в декоративном смысле. Это была естественная форма роста в стране, где активы собирались быстро, рынки менялись резко, риски были высокими, а управляемость часто держалась не столько на институтах, сколько на личных связях, собственности и центре принятия решений.
Холдинг позволял сделать то, что было нужно в тот момент: собрать производство, торговлю, склад, импорт, сервис, недвижимость, лабораторию, региональные площадки, финансовый контроль. Одни юридические лица закрывали операционные задачи, другие — имущественные, третьи — коммерческие, четвертые — внешнеэкономические. Так было удобнее, безопаснее и гибче. Так многие группы за двадцать лет выросли из семейных или региональных компаний в сложные промышленные организмы.
Эта форма не была ошибкой. Она была разумным ответом на свое время.
Ее логика понятна: операции могут быть распределены, но контроль должен быть собран. Разные активы живут своей жизнью, но центр удерживает деньги, стратегию, ключевые решения, кадровую рамку и общее чувство направления. В условиях определенной скорости среды это работало. Собственник, генеральный директор, финансовый директор и несколько сильных управленцев могли держать группу в голове. Не полностью, но достаточно для решений.
Сейчас та же архитектура начинает давать другой эффект.
Холдинг уже не просто набор активов. Он становится набором контуров. У каждого контура своя информационная среда, свой язык, своя скорость, свои правила доступа. Производство говорит на языке смен, линий, сырья, брака и ремонтов. Бухгалтерия — на языке проводок, закрытий, актов и налоговых рисков. Продажи — на языке клиентов, отсрочек, скидок и обещаний. ВЭД — на языке банковских каналов, инкотермс и валютных ограничений. Склад — на языке остатков, ячеек и пересорта. Руководитель — на языке ответственности за целое.
В холдинге 2000-х центр еще мог быть главным переводчиком между этими языками.
В холдинге 2020-х центр начинает уставать от этой роли.
Не потому, что люди стали хуже. Не потому, что собственник потерял хватку. А потому, что число связей выросло быстрее, чем способность одного центра удерживать их вручную. Чем больше систем, направлений, юридических лиц, банков, поставщиков, цифровых интерфейсов и внешних ограничений, тем дороже становится управлять через память, совещание и личное уточнение.
Холдинг 2000-х был архитектурой роста.
В 2020-х он рискует стать архитектурой перегрузки.
Старая мечта о едином контуре
У этой проблемы есть длинная история. Ее нельзя свести к тому, что «системы плохо интегрированы» или «люди не хотят работать в CRM». В глубине лежит старая управленческая мечта: сложность можно собрать в единый контур, если построить достаточно сильную систему.
В советской версии эту мечту яснее всего воплощал Виктор Глушков. В начале 1960-х он предложил идею общегосударственной сети вычислительных центров для управления экономикой; после 1963 года работа получила официальный ход. Позже проект вошел в историю под именем ОГАС. Замысел был грандиозным и внутренне последовательным: данные со всех заводов, регионов и министерств поднимаются наверх, обрабатываются, связываются с планированием и возвращаются вниз в виде управляющих решений. Страна как единый вычислительный контур.
Глушков не был кабинетным фантазером. Его мысль была инженерной и системной. Он видел то, что многие не видели: экономика слишком сложна, чтобы управлять ею бумагами, ведомственными каналами и задержками информации. Ему нужен был новый нерв управления, новая вычислительная ткань страны.
Но проект так и не запустили в задуманном виде, и причина важнее самого проекта.
Его не убили технологии. Его раздавила разнородность. Каждое ведомство хотело свою версию, свои справочники, свой контроль над своим куском данных. Согласование шло годами, обрастало компромиссами, и к концу 1970-х проект резко подорожал. Единый контур сломался не о нехватку машин. Он сломался о то, что реальность состояла из множества контуров, и каждый защищал свою границу.
Это первый урок, и он старше любой ERP. Мечту о едином центре губит не слабость технологии. Ее губит сопротивление множественности. Эту причину стоит запомнить: она встретится еще дважды, в разных десятилетиях и под разными именами, и каждый раз технология будет ни при чем.
Коммерческий мир пришел к той же мечте своим путем и с двух сторон. В 1972 году пятеро бывших инженеров IBM основали в Германии компанию, которая станет SAP. В 1987-м американская Oracle, выросшая из системы управления базами данных, открыла подразделение бизнес-приложений и выпустила Oracle Financials. Две разные родословные — немецкая заводская и американская программная — шли к одному обещанию: единые справочники, единые процессы, единые данные. Один контур, в котором закупка, склад, производство, продажи и финансы перестают жить порознь и начинают работать как части общей машины.
Когда в 1992 году SAP выпустила систему R/3, случилась тихая ирония, которую тогда мало кто заметил. R/3 был бегством от монолита — уходом от тяжелых мейнфреймов к распределенной клиент-серверной архитектуре. За два года он стал отраслевым стандартом. А следующие тридцать лет его и похожие на него системы продавали уже как новый монолит, в который нужно втянуть все.
Для промышленности это все равно было огромным шагом вперед. В хорошей ERP есть то, что бизнесу действительно нужно: дисциплина, транзакция, права доступа, журнал изменений, проводка, документ, остаток, маршрут согласования. Нажал кнопку — система не «подумала» и не «предложила». Она сделала. Сформировала документ. Списала материал. Провела операцию. Изменила состояние реальности внутри учета.
Здесь стоит сказать прямо, что автор пишет это не со стороны. Несколько лет назад наша группа переводила учет с 1С УПП версии 8.2 на 1С ERP версии 8.3 — со старого производственно-управленческого контура на новый. Это не катастрофа из деловой прессы, это рядовая миграция, через которую прошли тысячи компаний. Но именно поэтому она и научила простому. Учетная система не рассуждает и не угадывает. Период либо закрылся, либо не закрылся. Документ либо провелся, либо нет. Остаток либо сошелся, либо ты сидишь до ночи и ищешь, где он разъехался. Все, что написано здесь про природу строгих систем исполнения, написано человеком, который проводил среднюю промышленную компанию через смену такого контура и видел цену каждой неточности своими глазами.
Именно поэтому классические ERP до сих пор вызывают доверие. Они не всегда удобны, не всегда красивы, часто тяжелые и медленные в изменениях. Но промышленный человек понимает их природу. ERP принадлежит миру действия. Она либо провела операцию, либо нет. Либо дала право, либо не дала. Либо закрыла период, либо не закрыла. Это суровая, но понятная логика, и заводу она близка.
У этой мечты есть кладбище
Проблема в том, что чем сложнее компания, тем чаще попытка втянуть ее целиком в один контур заканчивается не управляемостью, а катастрофой. И это хорошо задокументировано.
В 1999 году компания Hershey, один из крупнейших производителей шоколада в мире, запустила новую корпоративную систему стоимостью около 112 млн долларов. Запуск назначили на осень, перед Хэллоуином — пиком годовых продаж. Система не заработала вовремя. Шоколад физически лежал на складах, но компания не могла его отгрузить: заказы примерно на 100 млн долларов остались невыполненными при полных складах. Квартальная прибыль упала на 19%. Вот природа детерминированной системы во всей наготе — она либо проводит операцию, либо не проводит, и когда она спотыкается, останавливается не отчет, а грузовик с товаром.
Дальше — жестче. Американский фармацевтический дистрибьютор FoxMeyer внедрял систему того же класса и обанкротился; неудачное внедрение стало одним из признанных факторов краха. Розничная сеть Lidl потратила на переход к SAP около семи лет и порядка 500 млн евро — и в 2018 году отказалась от проекта, вернувшись к прежней системе, потому что новая не справлялась с логикой учета запасов, принятой в Lidl. Обратите внимание на сам выбор: компания отказалась от системы, а не от собственной сложности.
И самый свежий случай, уже на другом вендоре. В апреле 2022 года Birmingham City Council — крупнейший орган местного самоуправления в Европе — запустил единую платформу Oracle Fusion вместо SAP, стоявшей с 1997 года. Один монолит меняли на другой. Бюджет оценивали примерно в 19 млн фунтов. К началу 2026 года прогнозная стоимость проекта дошла до 144 млн фунтов — более чем в семь раз выше. С момента запуска система проводила операции неверно: крупные массивы транзакций попадали не в те периоды, сверка банковских операций ломалась, а финансовый контур города долго оставался неустойчивым. В сентябре 2023 года совет фактически объявил о финансовой несостоятельности. Главным публичным фактором называли обязательства по equal pay, но провал Oracle-системы стал одним из тяжелых элементов кризиса: он подорвал отчетность и способность совета уверенно видеть собственные данные.
Автор знает Бирмингем не как строку в аудиторском отчете. Это большой, тяжелый, живой город, где люди платят налоги и водят детей в школы — те самые школы, которые в какой-то момент просто вывели за периметр проекта, чтобы сократить его масштаб. За цифрой в 144 млн фунтов стоит не абстрактная «крупнейшее муниципальное образование Европы», а реальность, которую монолит не смог вместить.
Между Hershey 1999 года и Birmingham наших дней — больше двадцати пяти лет, два континента, разные вендоры. Совпадает не вендор. Совпадает идея: собрать живую сложность в один контур и заставить ее там жить. Глушкова сломали ведомства. ERP ломается о компании. Причина та же: живую множественность не удалось заставить жить внутри одного контура.
Почему монолит перестал быть достаточным
Сказанное не означает, что ERP умерли. Они еще долго не исчезнут, потому что промышленность не может жить без слоя строгого исполнения. Производству, складу, бухгалтерии, закупке и финансам нужны системы, где действие фиксируется, проверяется и имеет последствия. Провалы внедрений — это не приговор ERP как классу. Это приговор идее, что одна система может быть всем.
Проблема в другом: ERP все хуже справляется с ролью единственной архитектурной метафоры компании.
Когда бизнес был проще, идея «все втянуть в одну систему» выглядела разумной. Если данные расходятся — унифицировать справочники. Если процессы неуправляемы — описать регламенты. Если филиалы живут по-разному — привести их к единому стандарту. Если руководитель не видит картину — собрать отчетность в одном месте. Это был нормальный управленческий здравый смысл.
Он и сейчас не стал глупым. Он стал недостаточным.
Современная компания слишком много знает о себе в местах, куда ERP не дотягивается естественным образом. В переписке с поставщиком есть смысл, которого нет в карточке контрагента. В записи совещания есть напряжение, которого нет в протоколе. В комментарии менеджера есть риск, которого нет в показателях. В банковском канале есть ограничение, которое еще не стало регламентом. В мессенджере есть договоренность, которую потом месяц ищут в письмах. В AI-чате есть черновик решения, который пока не принадлежит ни одной системе.
Каждая система знает кусок реальности. Ни одна не знает ее целиком.
Можно снова пытаться стянуть все в один центр. Но чем быстрее меняется среда, тем чаще компания обнаруживает, что пока она строит единый контур, реальность уже сменила поставщика, банк, канал платежа, упаковку, маркировку, юридическую формулировку, интерфейс или ответственного человека.
Монолит не исчезает. Он просто перестает быть достаточным ответом на множественность.
Поколения внутри системы
В одной компании живут не только разные системы, но и разные поколения управленческой культуры.
Старшее поколение руководителей формировалось в мире, где систему удерживали вертикаль, опыт, личная ответственность, производственная память и общий фон. Они умеют управлять там, где не все написано. Они считывают интонацию, понимают намек, знают, кто действительно взял задачу, а кто просто кивнул. Для них управление — это не только регламент, но и поле отношений, обязательств и невысказанных сигналов.
Поэтому цифровая разнородность для них часто выглядит как потеря контроля — не потому, что они не понимают компьютеры, а потому, что раньше связи между частями системы проходили через людей, которых они знали. Теперь эти связи размазаны между интерфейсами, чатами, задачами, таблицами, документами, внешними кабинетами и алгоритмами. То, что раньше можно было удержать взглядом и разговором, теперь нужно искать по слоям.
Об этом стоит сказать не отвлеченно. Несколько лет назад мы внедряли в группе корпоративный портал и мессенджер на базе Bitrix24. Технически это несложно. Сложным оказалось другое: заставить людей перенести в систему разговор, который двадцать лет шел в коридоре, по телефону и на словах. Часть команды, в основном старшего возраста, искренне не понимала, зачем писать в чат то, что можно сказать голосом. Внедрение шло через сопротивление, и какое-то время его приходилось, прямо скажем, вбивать сапогом.
А дальше произошло то, чего мы не закладывали. Молодые сотрудники приняли систему легче всех — и не просто приняли, а обжили. Общие чаты в Bitrix24 довольно быстро стали у них тем же, чем для них были обычные мессенджеры: средой с шутками, мемами, реакциями, лайками, живой интонацией. Туда переехала не только работа, но и культура. И это стоит считать здоровым признаком, а не отклонением. Система прижилась не там, где ее вводили силой, а там, где она совпала с естественной средой общения. Молодые не сопротивлялись цифровому контуру, потому что для них он не был чужим языком. Он был продолжением того, как они и так общаются.
Среднее поколение управленцев живет между двумя логиками. Оно уже привыкло работать в нескольких системах, но все еще часто выполняет роль живого интегратора. Такой человек знает, где в 1С лежит одно, где в Bitrix другое, какой файл на самом деле последний и где система формально права, но по жизни надо уточнить. Это поколение тащит на себе переход.
Младшие воспринимают многосистемность естественнее. Для них переключение между интерфейсами, чатами, задачами и окнами — нормальная среда. Они не испытывают трепета перед единой системой. Но у них часто слабее общий производственный фон, на котором держалась старая координация. Они быстрее переключаются, но не всегда видят, какая невидимая ответственность стоит за формулировкой, документом или задержкой.
Поэтому новый корпоративный протокол должен связывать не только данные. Он должен связывать поколения. Одной интеграции между 1С и CRM мало, если старший руководитель, средний управленец, молодой специалист и AI-модель по-разному понимают, что такое «задача выполнена», «договорились» или «срок критичен».
Здесь архитектура снова упирается в язык. И именно поэтому компания будущего должна научиться связывать не только базы, документы и интерфейсы, но и разные способы понимать управление.
Промышленность не принимает черновик
В этом месте особенно хорошо видно столкновение классической ERP и генеративных моделей.
ERP — система промышленного действия. Она не рассуждает о том, что, возможно, имел в виду пользователь. Она работает по правилам. Если правило плохое, результат будет плохим, но причина будет лежать внутри формальной логики: справочник, настройка, права, ошибка ввода, неверный маршрут, неправильный регламент. Это можно найти, разобрать, исправить, запретить, задокументировать.
Генеративная модель устроена иначе. Она не исполняет в строгом смысле. Она интерпретирует. Продолжает фразу. Строит вероятное объяснение. Предлагает формулировку. Собирает смысл из контекста. Иногда делает это блестяще. Иногда ошибается так убедительно, что ошибка выглядит как уверенное знание.
Для многих цифровых отраслей логика черновика привычна. Продукт выпустили, пользователи попробовали, команда собрала обратную связь, на следующей неделе обновили. Ошибка неприятна, но часто обратима: интерфейс поправили, функцию отключили, модель дообучили, релиз откатили.
Промышленность живет иначе. Нельзя выпустить черновик бетона. Нельзя запустить черновик завода. Стройка, производство, склад, рецептура, маркировка, отгрузка, безопасность, деньги и юридическая ответственность не прощают вероятностной двусмысленности. Ошибка уходит в материал, объект, клиента, транспорт, документ, акт, претензию. Реальность не обновляется как приложение.
И цифры здесь важны, но не так, как их часто подают. На узкой задаче с заданным источником — например, проверить короткий пересказ, — лучшие модели ошибаются редко: в отдельных тестах доля выдуманного держится около одного процента. Но узкая задача и реальная работа — разные вещи.
Если отдельный шаг надежен на девяносто девять процентов, цепочка из десяти шагов дает уже около девяноста процентов надежности, а тридцать–сорок шагов превращают почти идеал в рискованный результат. Публичные тесты автономных агентов показывают тот же эффект: на CRMArena-Pro сильные модели в одноходовых сценариях держались около 58% точности, а в многошаговых падали примерно до 35%; в TheAgentCompany лучший агент автономно доводил до конца около трети задач. Для промышленности это не лабораторная неточность, а граница между подсказкой и действием.
Этот разрыв между лабораторной точностью и реальной работой промышленность чувствует кожей раньше, чем читает отчеты. И рынок уже начинает считать его деньгами: Gartner ожидает, что более 40% проектов с автономными AI-агентами будут закрыты к 2027 году из-за стоимости, неясной пользы и слабого контроля рисков.
У этого разрыва есть имя и лицо. В начале 2024 года канадский трибунал разбирал дело Air Canada: чат-бот неверно объяснил клиенту порядок возврата по тарифу для летящих на похороны и пообещал скидку задним числом, хотя правила этого не допускали. Авиакомпания пыталась представить бота отдельной стороной, но трибунал отверг этот довод: компания отвечает за все, что говорит от ее имени, включая AI. Сумма была небольшой, но управленческий вывод оказался серьезным: машину нельзя поставить в графу «виновный».
Именно поэтому осторожность промышленности — не отсталость, а структурная зрелость. И чаще всех откатывают развернутого агента именно те, кто вложился в контроль и надзор сильнее других. Зрелость измеряется не тем, что ничего не сломалось, а тем, что есть чем поломку поймать и куда отступить.
Поэтому недоверие промышленности к генеративному AI не нужно описывать как отсталость. Это структурно оправданная осторожность среды, где действие должно быть проверяемым, ответственным и воспроизводимым.
Главное достижение ближайших лет будет не в том, что AI «заменит ERP». Это плохая формула. AI не должен становиться новой кнопкой, которая напрямую меняет промышленную реальность без правил ответственности. Его сила в другом. Он может быть слоем интерпретации, подготовки, проверки, перевода, сопоставления, объяснения, поиска слабых мест.
ERP остается слоем исполнения. AI может стать слоем понимания. Между ними нужен протокол доверия.
Средний слой между AI и ERP — возможно, главная архитектурная зона ближайших лет. Модель может читать письмо поставщика, сравнивать его с контрактом, вытаскивать риск, готовить поручение и объяснять расхождение. Но финальное действие — провести, списать, отгрузить, изменить, утвердить — должно проходить через строгую систему, роль, ответственность и след. К этому выводу компании приходят не из философии, а из синяков: рынок на ощупь нащупывает границу, за которой интерпретацию нельзя пускать в исполнение без подписи человека.
Промышленность примет генеративный AI не тогда, когда он станет похож на волшебный мозг. Она примет его тогда, когда станет понятна граница между вероятностной интерпретацией и детерминированным исполнением.
Три кладбища, один диагноз
Здесь стоит остановиться. Три неудачи в разных эпохах можно было бы счесть совпадением.
Сначала советская плановая экономика не смогла встроить ведомства в единый вычислительный контур. Потом западные корпорации обнаружили, что ERP не всегда выдерживает живую сложность компании. Теперь генеративный AI пытается собрать понимание организации в один разговорный интерфейс — и снова спотыкается о сопротивление множественности.
Это не догадка по аналогии. Нашумевший отчет MIT, проект NANDA, разобравший сотни корпоративных внедрений генеративного AI, дал цифру, которую потом много цитировали: лишь около 5% интегрированных пилотов извлекали измеримую ценность, а подавляющее большинство оставалось без заметного эффекта для прибыли. К самой цифре стоит относиться осторожно — методику отчета критиковали за громкость, и реальный вывод мягче лозунга. Но даже осторожные читатели согласились с главным, и это главное важнее процента. Причина провалов — не слабость моделей. Причина в том, что компании не смогли встроить новый инструмент в свою живую ткань: в процессы, роли, привычки, ответственность. MIT назвал это разрывом обучения. Мы в этой статье назвали это иначе — сопротивлением множественности, той самой причиной, которую увидели еще у Глушкова.
Три кладбища, разделенные десятилетиями, — и один и тот же диагноз во всех трех случаях: погибала не технология, погибала мечта собрать разнородное в один контур и заставить его там жить.
Если диагноз один, то и думать дальше надо не о том, как построить наконец правильный единый контур. Думать надо о другом — не о том, как все собрать, а о том, как связать то, что собрать уже нельзя. И вот здесь в разговор входит человек, который искал универсальность совсем не там, где Глушков.
Шеннон и другой тип универсальности
В 1948 году Клод Шеннон опубликовал в Bell System Technical Journal работу «A Mathematical Theory of Communication» — в двух частях, в июльском и октябрьском выпусках. Она была не о менеджменте, заводах, ERP или холдингах. Она была о связи: о сообщении, канале, шуме, кодировании, потере, избыточности.
Но именно поэтому она важна для разговора о корпоративном управлении сегодня.
Шеннон сделал шаг, который кажется парадоксальным. Он вынес смысл сообщения за скобки. В его теории информационное содержание сообщения не имеет отношения к тому, что сообщение значит, — только к тому, сколько в нем выбора, сколько неопределенности оно снимает. Это позволило описывать передачу информации поверх различий конкретных каналов. Телеграф, телефон, радио, шумный провод — все оставалось разным. А закон передачи оказался общим. Шеннон доказал, в частности, что если поток информации от источника не превышает пропускной способности канала, существует способ кодирования, позволяющий передать сообщение почти без ошибок даже сквозь шум.
Он не изобрел связь. Он обнаружил закон, который уже действовал в любом канале.
В этом и есть принципиальное отличие шенноновской универсальности от привычной управленческой мечты о единой системе. Универсальное не обязательно означает одинаковое. Иногда универсальность — это не общий центр, а общий способ описать связь между разными средами. Не один язык, на котором все обязаны говорить, а закон, позволяющий понять, что происходит при передаче сообщения из одного контура в другой.
Глушков и Шеннон искали универсальность в одну эпоху, почти не пересекаясь. Но искали разное. Глушков пытался построить архитектуру управления — собрать страну в один контур. Шеннон искал закон связи — и нашел его именно потому, что не пытался ничего собрать в одно место. Один строил центр. Другой описывал связь. Через семьдесят лет оказывается, что для современной компании второй подход практичнее первого.
Если у нас есть производство, склад, продажи, банк, бухгалтерия, ВЭД, CRM, AI, мессенджеры и внешние кабинеты, вопрос уже не только в том, как заставить всех жить в одной системе. Правильнее спросить иначе: как сообщение переходит между этими средами? Где оно теряет смысл? Где появляется шум? Где нужна избыточность? Где нужен человек, а где машина? Где нужна строгая транзакция, а где достаточно подсказки? Где интерпретация должна остановиться перед действием?
Вот здесь начинается шенноновская логика управления. Не система, которая все собирает внутри себя. А правила связи между тем, что уже не может быть собрано в одном месте.
Закон связей нельзя придумать
У каждой компании уже есть свой закон связей. Он просто редко описан.
В одном холдинге все важные решения по-настоящему проходят через финансового директора, даже если формальный маршрут согласования другой. В другом настоящим центром знания оказывается начальник склада, потому что только он понимает физическую реальность остатков. В третьем коммерческий директор держит клиентов лучше любой CRM. В четвертом главный технолог знает, почему формально одинаковые партии ведут себя по-разному. В пятом вся система поставок держится на человеке, который помнит, какой банк через какой маршрут еще проводит платежи.
Это не всегда хорошо. Но это реально.
Когда компания внедряет новую систему, она часто пытается нарисовать идеальную архитектуру сверху. Как должно быть. Где должен быть центр. Какие справочники главные. Какой процесс правильный. Это нужно, но этого мало. Под формальной схемой уже существует живая сеть связей, обходов, уточнений, доверия, памяти и неформальных протоколов. Если ее не увидеть, новая система будет бороться не с хаосом, а с реальностью — и проиграет, как проиграли монолиты из предыдущих разделов.
Закон связей нельзя просто придумать в кабинете консультанта. Его нужно найти. Так же как Шеннон не придумал связь, а описал то, что уже действовало в любом канале, компания должна обнаружить, как в ней на самом деле движутся данные, решения, ответственность, товар, деньги, документы и смысл. Только после этого можно строить протокол — не как еще одну инструкцию, а как очищенную форму уже существующей связи.
И у каждого холдинга этот закон свой. Своя история роста, свои активы, свои сильные люди, свои слабые места, свои неформальные маршруты, свои зоны шума и точки потери смысла. Нельзя купить универсальный порядок как коробку. Нельзя скачать зрелость архитектуры вместе с обновлением. Можно только внимательно посмотреть на собственную систему и выдержать ее сложность достаточно долго, чтобы разглядеть в ней уже существующие связи.
От монолита к протоколу
Если назвать главный сдвиг одним выражением, он звучит так: управляемость переезжает из центра в протокол.
Это не значит, что центр больше не нужен. Нужен. Собственник, генеральный директор, финансовый контур, стратегия, ответственность, право окончательного решения — все это никуда не исчезает. Компания без центра превращается не в сеть, а в шум.
Но центр больше не может быть единственным местом, где рождается связность. В старой логике он должен был все увидеть, все собрать, все согласовать, все удержать и все вернуть вниз в виде решения. В новой логике центр задает правила, по которым части системы обмениваются данными и смыслом без постоянного ручного вмешательства.
Это и есть переход от монолита к протоколу.
Монолит отвечает на вопрос: где центр? Протокол отвечает на вопрос: как связаны части?
И здесь стоит сказать трезво: рынок движется быстрее, чем готова осторожная промышленность. То, что раньше называли распадом монолитной ERP на слабо-связанные облачные приложения, сегодня стало зрелым трендом, и в нем появились автономные AI-агенты, которые не подсказывают, а действуют. Рынок толкает компании к автономному действию машин быстрее, чем промышленность готова отдать им ответственность.
Поэтому позицию стоит сформулировать прямо, а не растворять в общем оптимизме. Будущее корпоративной архитектуры не в том, чтобы отдать AI ключи от системы, а в том, чтобы встроить его в протоколы ответственности. Где модель предлагает — человек утверждает. Где модель объясняет — система исполняет. Где модель видит риск — регламент фиксирует действие. Где модель переводит смысл — учетная система проводит реальность.
Такой контур уже не глушковский. Он шенноновский. Не потому, что в нем нет управления, а потому, что управление строится вокруг связи между разными средами, а не вокруг центра, который пытается все собрать.
Не один язык, а способность связи
Новый корпоративный язык, скорее всего, не будет создан одной платформой. Ни SAP, ни Oracle, ни 1С, ни Bitrix, ни OpenAI, ни Сбер, ни Яндекс, ни китайские модели не дадут всем компаниям один универсальный способ управлять сложностью. Каждая система будет сильна в своем контуре. Каждая будет тянуть центр тяжести к себе. Каждая будет обещать, что именно вокруг нее можно собрать порядок.
Но порядок может оказаться не внутри одной из них. Он может возникнуть между ними.
В том, как данные переходят из склада в финансы. Как решение совещания превращается в задачу. Как письмо поставщика становится строкой риска в контракте. Как подсказка модели становится не действием, а подготовкой к действию. Как старший руководитель видит цифровую среду не как потерю контроля, а как новый тип связности.
Возможно, именно здесь и будет найден закон связей каждой конкретной компании. Не общий для всех. Но универсальный внутри ее собственной сложности.
Будущее управления не в отказе от ERP, не в поклонении AI, не в ликвидации холдингов, не в новом универсальном интерфейсе и не в мечте о системе, которая наконец-то все поймет за нас. Будущее управления — в способности увидеть, как уже связаны части живой компании: где связь рвется, где искажается, где требует человека, где машины, где строгого действия, а где только перевода смысла.
Поэтому задача уже не в том, чтобы просто выдержать сложность, а в том, чтобы навести в ней связь. Порядок здесь не вводят сверху и не покупают коробкой. Его находят в том, как части уже говорят друг с другом, и закрепляют протоколом. И тогда из множественности проступает не хаос, а структура — не потому, что ее построили, а потому, что ее наконец увидели.
Алексей Деменок · Holliday Intelligence · № 05 · 02 июня 2026