От ERP к управлению контекстом: как меняется роль CIO в эпоху искусственного интеллекта

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

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

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

В разработке программного обеспечения оценка сложнее. ИИ ускоряет написание кода, подготовку документации, тестирование — но итоговый эффект зависит от зрелости процессов разработки, архитектурных стандартов и того, насколько команда умеет пользоваться новыми инструментами. Мы, например, внедрили собственную ИИ-платформу, которая объединила в едином защищенном контуре данные о клиентах, проектах, документах и накопленной экспертизе. В отдельных сценариях время подготовки типовых документов и проектных материалов сократилось на 25–30%, а время поиска необходимой информации до 40%. Срок погружения новых сотрудников в проект в среднем удалось сократить с пяти до трех рабочих дней.

Крупные компании располагают огромным объёмом информации, но количество данных не равно знанию. Информация распределена между ERP, CRM, MES, аналитическими платформами, архивами и базами документов. Отдельные подразделения знают свои процессы, но у компании редко есть единое описание того, как работает организация в целом.

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

Таким образом ключевой вопрос для компании меняется. Раньше клиенты спрашивали: «как подключить ИИ к нашим данным?», сейчас: «как описать бизнес так, чтобы ИИ мог работать внутри него?».

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

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

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

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

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

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

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

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

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

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

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

1. Какой процесс меняем и какой эффект измеряем

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

2. Описан ли процесс так, чтобы его можно было передать ИИ-агенту

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

3. Какие данные — источник истины

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

4. Что можно делегировать ИИ

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

5. Готова ли архитектура к работе агентов

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

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

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