Где ваша методология «цифровизации»? Почему ERP, MES и PLM уже не равны цифровой трансформации

Получил очередное приглашение на мероприятие по цифровизации промышленности. В программе всё знакомо: ERP, MES, PLM, 1С, производственный контур, импортозамещение, интеграции, производственные решения, новые продукты и очередная панельная дискуссия о том, куда движется российская промышленность. Сама по себе такая программа нормальна: предприятиям действительно нужны системы, интеграции и прикладные решения. Но чем больше я смотрю на этот привычный набор слов, тем сильнее возникает один простой вопрос: а что мы сегодня вообще называем цифровой трансформацией?

Внедрение ERP? Интеграцию ERP с MES? Замену импортной PLM? Подготовку регламентов? BI-панель? Электронный документооборот? Производственную аналитику? Новые рабочие места в системе? Всё это может быть полезно, а иногда и совершенно необходимо. Проблема начинается в тот момент, когда обычная автоматизация, внедрение или интеграция начинают называться цифровой трансформацией предприятия.

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

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

Оцифровка, цифровизация и цифровая трансформация — это не одно и то же

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

ERP, MES, PLM, BI, ЭДО и интеграции могут быть частью цифровизации. Они могут быть очень важной частью, без которой предприятие просто не сможет нормально работать. Но сами по себе они не доказывают цифровую трансформацию. Поставить систему — ещё не значит построить цифровую модель предприятия. Связать несколько систем между собой — ещё не значит получить управляемую модель деятельности. Выпустить набор регламентов — ещё не значит создать цифровой двойник предприятия.

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

Что часто продаётся под видом цифровизации

Обычный набор знаком всем, кто работает с промышленными предприятиями: ERP, MES, PLM, WMS, BI, ЭДО, миграция с SAP на 1С, импортозамещение, интеграции, витрины данных, производственные панели, регламенты, рабочие места, маршруты согласования и отчёты. Всё это может быть нужно. Более того, без транзакционного и исполнительного слоя предприятие быстро возвращается к ручной памяти ^[1] сильных сотрудников, Excel-файлам, перепискам и бесконечным совещаниям.

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

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

Главный вопрос: где ваша методология?

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

Как вы выделяете предметные области? Как описываете объекты управления? Как фиксируете их состояния и события? Как связываете их с бизнес-процессами, ролями, процедурами, ERP, MES, PLM, СМК, ГИС, управленческим учётом, финансами, KPI, рисками, персоналом и SMART-действиями? Где это можно почитать, какие артефакты производит ваша технология, как по ней работает аналитик, как проверяется результат и что происходит с моделью после завершения проекта?

Если методология существует, её можно предъявить хотя бы в общих чертах: этапы, артефакты, правила, контроль качества, примеры моделей и границы применимости. Если её нельзя прочитать, проверить и воспроизвести, то это не методология. В лучшем случае это накопленный внедренческий опыт ^[2], внутренняя легенда компании о самой себе и набор привычных проектных приёмов.

Какие предметные области у вас описаны?

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

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

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

Объекты управления или объекты метаданных?

Одна из главных ошибок цифровизации — подмена объектов управления объектами метаданных ERP. Документ ERP — это не обязательно объект управления. Справочник — не онтология предприятия. Регистр — не бизнес-предмет. Статус в системе — не всегда состояние управляемой сущности. Форма ввода — не модель деятельности, а кнопка тем более не методология.

Объект управления — это то, чем предприятие реально управляет: потребность ^[3], заказ, партия, поставка, производственное задание, маршрут, рекламация, несоответствие, обязательство, лимит, риск, отклонение, решение, ресурс, изделие, версия, заявка или операция. У такого объекта есть границы, состояния, события, владельцы, носители, источники, связи с процессами, показатели и правила изменения.

Если компания не различает объект управления и объект системы, она не строит цифровую модель предприятия. Она строит модель того, как выбранная система умеет отражать отдельные фрагменты предприятия. Поэтому вопрос к любому цифровизатору очень простой: есть ли у вас библиотека объектов управления, какие предметные области она покрывает, как она специализируется под отрасль, как из неё выводятся бизнес-процессы и как она связана с ERP, MES, PLM, СМК, ГИС, KPI, финансами и персоналом?

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

А BPMN, ArchiMate и TOGAF?

Здесь стоит снять ожидаемое возражение. Речь не о том, что автор не знает BPMN, ArchiMate, TOGAF, EPC, UML и другие нотации описания процессов и архитектуры предприятия. Знаем, использовали, понимаем, зачем они нужны. BPMN полезен, когда человеку нужно увидеть процесс: события, задачи, шлюзы, роли и потоки. ArchiMate полезен, когда нужно представить архитектурные слои предприятия: бизнес, приложения, данные, технологии, мотивацию ^[4] и зависимости. ArchiMate поддерживается The Open Group и используется как язык моделирования enterprise architecture рядом с архитектурной рамкой TOGAF.

Но все эти нотации не должны быть первичным хранилищем смысла цифровой модели. BPMN, ArchiMate, TOGAF и похожие инструменты — это человекочитаемые представления. Они нужны для согласования, контроля, обсуждения, визуальной проверки и коммуникации между людьми. Машинному ядру всё равно, нарисуете вы представление в BPMN, ArchiMate, EPC, UML, таблице или собственной нотации. Машинное ядро должно хранить не картинку, а сущности и связи: предметные области, бизнес-предметы, состояния, события, процедуры, роли, источники, GAP, KPI, риски, цифровую нить и правила актуализации.

В зрелой технологии процессные и архитектурные схемы должны выводиться из графа знаний, а не заменять его. Мы не спорим с BPMN, ArchiMate и TOGAF как с инструментами человекочитаемого описания. Мы спорим с подменой машинного ядра предприятия электронным кульманом — ручным рисованием схем процессов и архитектуры. Если схема нарисована вручную и лежит отдельно, это электронный кульман. Если схема выводится из машинного ядра, связана с бизнес-предметами, процедурами, ERP-фактами, СМК-записями, KPI, тестами и цифровой нитью, тогда это уже представление цифровой модели.

Как вы встраиваете СМК, учёт, финансы, ГИС, персонал и KPI?

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

Здесь уже недостаточно сказать: «мы описываем бизнес-процессы». Нужно показать, как СМК встраивается в процедуру, где возникает запись качества, где фиксируется несоответствие и как корректирующее действие связано с бизнес-предметом. Нужно объяснить, как накладывается управленческий учёт, какие объекты управленческого учёта выделены, где возникают лимиты, затраты, себестоимость, бюджеты и план-факт. Нужно показать, как хозяйственное событие становится финансовым следствием, как внешний ГИС-контур возвращает статусы, как это связано с процедурой, и где в модели появляются роль, ответственность, KPI сотрудника, мотивация ^[5] и SMART-действие.

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

Документы из графа знаний или цифровые бумажки?

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

Документы сами по себе не являются цифровой моделью предприятия. Они являются ее человекочитаемыми представлениями. Регламент, СОП, ERP-инструкция, документ СМК, должностная инструкция, KPI-карта, тестовый сценарий и LLM-контекст не должны жить как отдельные Word-файлы, подготовленные вручную и забытые после подписания акта. Они должны быть производными представлениями из машинного ядра и графа знаний.

Сначала должна быть цифровая модель: предметные области, объекты управления, процессы, процедуры, роли, состояния, события, источники, GAP, KPI, риски, цифровая нить и связи с системами. Уже из неё должны выводиться человекочитаемые документы, visual-схемы, тесты, инструкции, LLM-контексты и управленческие действия. Если каждый документ создаётся отдельно, без общей модели, без трассировки, без источников, без версий и без механизма актуализации, предприятие получает не цифровую модель, а ещё один слой быстро устаревающих документов.

Где хранится цифровая модель предприятия?

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

Цифровая модель должна жить выше уровня отдельных систем: в машинном ядре, графе знаний, онтологическом слое, где ERP, MES, PLM, СМК, ГИС, BI и документы выступают носителями и источниками, но не подменяют модель. Иначе мы получаем набор цифровых следов без связной памяти предприятия. В таком случае ИИ сможет пересказывать документы и строить правдоподобные ответы, но не сможет надёжно объяснять деятельность предприятия, потому что у него нет устойчивого предметного контекста.

Где ваша цифровая нить?

У цифрового двойника деятельности должна быть цифровая нить. Не красивая метафора, а трассировка: откуда взялся объект управления, каким источником он подтверждён, каким вопросником уточнён, в какой предметной области живёт, в какой процесс входит, какой процедурой изменяется, каким ERP-документом фиксируется, какой записью СМК подтверждается, какой KPI затрагивает, какое отклонение породил, какое решение принято и как это решение обновило модель.

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

Как модель живёт после акта?

Цифровая трансформация не может быть устроена по схеме «обследовали, описали, внедрили, подписали акт, получили деньги и разошлись». Предприятие меняется постоянно. Меняются маршруты, роли, документы, требования СМК, статусы ERP, внешние ГИС, KPI, ответственные, нормативные требования, поставщики, клиенты, риски, логистика и ограничения. Поэтому главный вопрос звучит просто: как ваша модель следует с предприятием?

Здесь важны уже не лозунги, а эксплуатационная дисциплина. Кто владелец графа знаний? Кто обновляет цифровую нить? Как версионируются предметные области, процессы, процедуры и KPI? Как изменение в ERP отражается в модели? Как изменение в СМК отражается в процедурах? Как меняется тестовый сценарий после изменения бизнес-процесса? Как LLM узнаёт, что старый контекст больше не актуален?

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

Как вы проверяете модель?

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

Часть маршрута останется ручной: физический контроль, экспертное решение, СМК-запись, внешний регуляторный контур. Часть будет гибридной: ERP-шаги проверяются автоматически, а смысловая и физическая часть проверяется экспертом. Но зрелая методология должна явно различать ручное, автоматизированное и гибридное тестирование, а не ограничиваться тем, что аналитик вручную «покликал» по системе и написал, что всё работает.

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

Palantir, SAP, Oracle: куда движется мировая рамка

Можно по-разному относиться к западным вендорам, спорить с их маркетингом и не принимать их архитектурные решения. Но направление рынка видно: крупные технологические игроки уже не ограничиваются разговором «внедрим ERP и интегрируем контуры». Они идут в сторону онтологий, графов знаний, семантических слоёв, AI-агентов и управляемого контекста.

Palantir строит разговор вокруг Ontology как операционного слоя организации: поверх цифровых активов, с объектами, связями, действиями, логикой ^[6] и безопасностью. SAP продвигает Knowledge Graph как средство, которое связывает данные компании с AI для точных и контекстных ответов и помогает снижать галлюцинации. Oracle развивает RDF Graph и семантические технологии в базе данных, включая работу с RDF, RDFS и OWL.

Это не значит, что нужно копировать Palantir, SAP или Oracle. Но это значит, что мировой язык enterprise AI уже движется в сторону онтологий, графов знаний, цифровых двойников, семантического контекста и управляемых действий. Тогда вопрос к российским локомотивам цифровизации промышленности становится вполне конкретным: куда ведёте вы? В ERP, MES, PLM и очередную панель показателей — или в предметную модель, граф знаний, цифровую нить и AI-ready предприятие?

Почему после 2025 года всё изменил ИИ

До недавнего времени можно было спорить, достаточно ли для цифровизации ERP, MES, PLM, BI, ЭДО и интеграций. После 2025 года спор стал другим. LLM и AI-агенты резко подняли планку, потому что теперь предприятию недостаточно хранить данные и проводить документы. Оно должно объяснять собственную деятельность человеку, системе и ИИ.

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

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

Это уже вопрос конкурентоспособности

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

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

Поэтому вопрос «куда движется российская промышленность?» нельзя сводить к внедрению ERP, MES и PLM. Вопрос должен звучать иначе: движется ли она к интеллектуальным предприятиям или к очередному поколению автоматизированных, но методологически несвязанных систем?

Короткий чек-лист для тех, кто говорит о цифровой трансформации

Если проект называется цифровой трансформацией, можно задать несколько простых вопросов. Где описана методология построения цифровой модели предприятия? Какие предметные области уже описаны? Что является базовой единицей модели: функция, процесс, документ, объект метаданных или объект управления? Есть ли библиотека бизнес-предметов и объектов управления? Как отличают бизнес-предмет от ERP-документа, справочника, регистра и статуса? Как описаны состояния, события и жизненный цикл объекта управления?

Дальше вопросы становятся ещё предметнее. Как из бизнес-предметов выводятся бизнес-процессы? Как в процедуры встраиваются СМК, управленческий учёт, финансы, ГИС, риск, персонал, KPI и SMART-действия? Где фиксируются источники, GAP, спорные места и правила проверки? Где машинное ядро: Excel-core, граф знаний, онтология, реестр связей? Где цифровая нить? Как модель обновляется после изменений предприятия?

И, наконец, как модель проверяется: вручную, автоматически, гибридно? Используются ли автоматизированные сценарии проверки в ERP, например Vanessa Automation? Какие документы выводятся из модели: регламенты, СОП, ERP-инструкции, СМК-документы, KPI-карты, должностные инструкции, тесты и LLM-контексты? Если на эти вопросы нет ответов, перед нами может быть автоматизация, внедрение, интеграционный проект или полезное импортозамещение. Но цифровой трансформацией это называть рано.

От автора

Вообще-то до этого приглашения на очередную «цифровизацию» я собирался написать на Хабр совсем другую, добрую статью — «Какая жена нужна айтишнику». Хотелось написать человеческий текст о человеке рядом, о поддержке, о семье и о том, почему нормальная жизнь за пределами проектов иногда важнее самих проектов.

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

Кстати, в июле похоже завершу переговоры с издательством по публикации моего двухтомника “о реальной методологии “цифровизации”. Обязательно размещу пост на Хабр со ссылкой.

Справочные источники

1. The Open Group. ArchiMate Enterprise Architecture Modeling Language: https://www.opengroup.org/archimate-forum/archimate-overview ^[7]

2. The Open Group. TOGAF Standard: https://www.opengroup.org/togaf ^[8]

3. Palantir Foundry Documentation. Ontology Overview: https://palantir.com/docs/foundry/ontology/overview/ ^[9]

4. Palantir Foundry Documentation. The Ontology system: https://palantir.com/docs/foundry/architecture-center/ontology-system/ ^[10]

5. SAP. SAP Knowledge Graph: https://www.sap.com/products/artificial-intelligence/ai-foundation-os/knowledge-graph.html ^[11]

6. Oracle Database Documentation. RDF Graph Overview: https://docs.oracle.com/en/database/oracle/oracle-database/21/rdfrm/rdf-semantic-graph-overview.html ^[12]

7. GitHub. Vanessa Automation / Pr-Mex: https://github.com/Pr-Mex/vanessa-automation ^[13]