Цифровизация без иллюзий - Рабочая сфера Владимира Лемеха

1. Подмена результата формулировкой

Публичные отчёты о цифровых проектах в промышленности часто строятся одинаково. Называют актуальную тему – «цифровая платформа», «Индустрия 4.0», PLM, ERP, «интеллектуальная система» – ссылаются на государственную программу, перечисляют участников и обозначают ожидаемый эффект. При этом не хватает самого предмета оценки: что именно создано, в каком состоянии оно находится, кто этим пользуется и что изменилось в производстве.

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

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

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

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

2. Исследование, разработка, внедрение: разные классы результатов

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

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

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

3. Что такое промышленная цифровая платформа

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

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

Единая модель данных. Объекты (изделие, состав, технологический процесс, ресурс) описаны один раз, с версионностью и однозначной идентификацией. Если одна сущность живёт в нескольких системах в разных представлениях, это связка систем, а не платформа.
Формализованные интеграционные контракты. Интерфейсы, форматы, правила обмена и разрешения конфликтов данных описаны и верифицируемы. Передача файлов между системами интеграцией не является.
Эксплуатация владельцем процесса. Платформа используется в штатной деятельности, на ней замкнуты реальные операции: согласование изменений, запуск в производство, учёт. Если процесс можно выполнить без неё, она в процесс не встроена.
Управление данными и ответственность. Определены владельцы данных, правила качества, регламент изменений. Иначе технический результат деградирует после завершения проекта.
Воспроизводимость. Слово «типовая» требует как минимум двух независимых внедрений в разных условиях с описанием того, что пришлось изменить. Одно внедрение – кейс, а не типовое решение.

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

4. Ресурсная состоятельность разработчика

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

Сбалансированный коллектив (демонстрационный пример)

Условия: пилотная платформа цифрового двойника производственного объекта (линия или установка). Цель – двойник, который воспроизводит текущее состояние и поведение объекта в штатном режиме. Состав: единая модель объекта (геометрия, состав, узлы, режимы), интеграция с АСУ ТП и учётными системами (датчики, SCADA, MES/ERP), пилот на одном объекте, 12 месяцев, 1 человеко-месяц = 160 чел-ч.

Этапы: М1-2 – обследование объекта, инвентаризация источников данных и критериев достоверности; М3-5 – архитектура двойника, единая модель и правила синхронизации; М6-9 – разработка, подключение потоков данных, калибровка; М10-11 – опытная эксплуатация и сверка с объектом; М12 – приёмка, регламент сопровождения.

Табл.1 – Разработка пилотной платформы цифрового двойника производственного объекта (линия или установка)

Средняя загрузка – 5,6 ставки, пик 7,25 ставки (М8-М10).

Почему такой коллектив считают сбалансированным:

Программирование занимает меньшую часть ресурса. Разработка (симуляция, backend, визуализация) – 39,8%. Остальные 60% приходятся на то, без чего двойник не становится рабочим: модель объекта, предметная экспертиза, качество данных, верификация, безопасность, внедрение.
Компетенции предшествуют коду. Архитектор, технолог объекта и специалист по моделированию данных работают с первого-второго месяца; программисты подключаются после фиксации модели и правил синхронизации с АСУ ТП.
Нагрузка соответствует стадии. Обследование и модель падают к середине проекта, разработка и подключение датчиков пиково растут, на М1-М12 доминируют сверка с объектом и передача в эксплуатацию.
Есть независимая проверка. Верификация моделей и QA (8,2%) выделены отдельной ролью: двойник без сверки с объектом – это 3D-сцена, а не модель.
Нет единичных точек отказа. Ключевая компетенция (симуляция/backend) дублируется.

Для любого описания проекта проверяют пять вещей.

Достаточность. Хватает ли суммарных чел-ч для заявленного охвата? Ориентир – проекты-аналоги или собственная декомпозиция работ.
Структура. Доля разработки обычно в районе 35-45%, а аналитика, архитектура и данные – не менее трети (в примере А 34,6%). Это ориентиры для демонстрации, а не нормативы; для конкретного проекта их нужно обосновывать.
Тестирование и безопасность. Выделены ли они самостоятельными ролями с ненулевой нагрузкой на всём протяжении разработки?
Динамика. Соответствует ли профиль нагрузки по месяцам стадиям проекта? Ровная «полочка» на весь срок обычно означает, что график рисовали под отчётность.
Реальность загрузки. Нет ли исполнителей, которые суммарно по проектам числятся более 1,0 ставки?

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

5. Экономическая модель цифровизации

Экономику цифровизации часто подменяют формулой загрузки: сколько ставок на проекте, сколько часов продано, какая доля ФОТ «отбилась» на внедрении. Это модель труда разработчика, а не экономика цифровизации. Заказчик не покупает занятость коллектива и не покупает перепроданные часы: он покупает изменение производственного результата, которое без системы не наступило бы.

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

Эффект подписчика платформы состоит в воспроизводимых изменениях на стороне процесса. Для промышленного объекта это, как правило:

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

Важно, что эффект – не синоним «цифровизации». Это конкретные денежные или натуральные величины, которые можно снять с отчётности предприятия: часы простоя, тонны брака, киловатт-часы, оборачиваемость, календарный срок освоения изделия. Без этих величин эффект существует только в презентации.

Рабочая экономическая модель проста: создаём эффект и забираем согласованный процент. Денежный эффект – не фигура речи. Это суммы, которые уже проходят по бухгалтерии и производственному учёту подписчика: выручка от недополученного сбоя, экономия по статье затрат, сокращение сверхнормативных остатков. Эффект, которого нельзя показать в учёте, делить не с чем. Процент – это цена результата. Он фиксируется заранее и привязывается к подтверждённой базе, а не к трудозатратам поставщика. Такая конструкция переворачивает интересы: поставщику становится невыгодно раздувать штат и сроки, ему выгодно быстрее довести процесс до измеримого улучшения. Заказчику, наоборот, проще проверить один результат, чем разбирать смету часов.

Минимальные условия, при которых модель работает:

База. До внедрения зафиксированы те показатели, из которых будет считаться эффект: простои, брак, запасы, энергия, сроки. Без базы процент не к чему применять.
Атрибуция. Изменение должно быть связано с работой платформы, а не с сезоном, новым оборудованием или изменением плана. Достаточно заранее согласовать правило: что входит в эффект, а что остаётся у подписчика.
Прозрачность учёта. Обе стороны видят одни и те же данные. Скрытая методика расчёта превращает модель в спор о выкладках.
Совпадение горизонта. Процент берётся с достигнутого эффекта в согласованном периоде, а не «с обещания» на весь жизненный цикл платформы.
Граница и потолок. Определены пределы выплат, срок действия соглашения и порядок действий, если эффект не достигнут.

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

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

6. Анатомия имитации

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

Антипаттерн 1. Выдача намерений за завершенный объект

Из отчета:
«РЕАЛИЗОВАННЫЕ ПРОЕКТЫ. Интеграционное решение для промышленной кооперации. Предпроектные мероприятия по созданию интеграционного межплатформенного решения… Участники: ОАО «ЦНИИТУ» и ГК «Росатом».

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

Почему так делать нельзя:
«Мероприятия» и «решение» – это разные онтологические категории. Мероприятия – это процесс (совещания, сбор требований, написание ТЗ, протоколы о намерениях). Решение – это материальный программно-аппаратный артефакт (развернутые шины данных, работающие коннекторы, согласованные API). Называть разработку требований «реализованным решением» – прямая манипуляция.

Дымовая завеса:
Упоминание Союзного государства и статусных участников («Росатом», «ЦНИИТУ») призвано компенсировать отсутствие предмета оценки. Авторитет участников используется вместо демонстрации работающего продукта.

Антипаттерн 2. Подмена внедрения платформы методичкой и уход в «суррогатные индексы»

Из отчета:
«Исследование принципов промышленной цифровой платформы «Индустрия 4.0»… Проведено научное обоснование принципов… Разработаны типовые модели… и практические рекомендации по внедрению систем PLM, ERP… Прогнозируемый эффект – рост индекса цифрового развития организаций на 0,25–0,36».

В чем подмена:
Заголовок обещает крупный технологический прорыв – «Цифровую платформу Индустрия 4.0». В теле описания результатом оказываются «обоснование принципов» и «рекомендации по внедрению стороннего ПО (PLM, ERP)». Платформа не создана даже в виде альфа-версии. Создан научно-технический отчет с советами, как внедрять чужие системы.

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

Суррогатный эффект:
«Рост индекса цифрового развития на 0,25–0,36». Это вершина имитационной цифровизации. Индекс цифрового развития – синтетический бумажный конструкт. Он не отражается в бухгалтерском или управленческом учете завода. От роста индекса на 0,3 станки не начинают работать точнее, брак не снижается, себестоимость не падает. Экономический результат подменен отраслевым коэффициентом, созданным самими же составителями отчетов для самоотчета.

Антипаттерн 3. Словарь благозвучной неопределенности

Из отчета:
«Интеллектуальная система цифрового проектирования и подготовки производства. Проект реализован на базе ОАО «ММЗ Вавилова» и ОАО «Витязь»… Внедрение системы обеспечило цифровую прослеживаемость… сократило сроки вывода новых изделий на рынок и повысило эффективность управления разработкой…»

В чем подмена:
Формально заявлена высокая стадия (НИОК(Т)Р, «внедрение»), однако описание составлено в превосходных степенях без единого верифицируемого факта:

Отсутствие базы и метрик. Фраза «сократило сроки вывода» методически ничтожна, если не указано: с каких сроков до каких, на каком конкретно изделии или технологическом процессе и относительно какой базы сравнения. Сокращение на 3 часа или на 4 месяца?
- Размытость границ. Что значит «реализован на базе заводов»? Система установлена на одном компьютере ведущего конструктора для демонстрации или стала обязательным шлюзом, без которого цех не имеет права запустить деталь в производство? Если второй конструктор завода продолжает носить чертежи на флешке или бумаге в обход этой «системы», внедрения не произошло.
- Магическое слово «интеллектуальная». Термин используется как украшение. В тексте нет ни слова о том, в чем состоит «интеллект» системы: это алгоритмы оптимизации раскроя, нейросетевой контроль дефектов, предиктивный анализ режимов или просто скрипт валидации полей в интерфейсе.

Сводные маркеры имитации

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

Глаголы процесса вместо фиксации артефакта: «проводились работы», «прорабатывались вопросы», «обосновывались подходы».
Абстрактные индексы вместо натуральных величин: «рост цифровой зрелости», «повышение инновационного потенциала».
Безотносительные сравнительные степени: «сроки сократились», «эффективность повысилась», «прослеживаемость улучшилась».
Статусный щит: перечисление 5 министерств, 3 академий и 2 госкорпораций в тексте объемом 4 предложения. Чем меньше технической сути в релизе, тем больше в нем упоминаний программ и ведомств.

7. Вывод

Цифровизация в промышленности перестает быть имитацией ровно в тот момент, когда риторика презентаций заменяется проверяемыми фактами. Зрелость проекта подтверждают не громкие названия («Индустрия 4.0», «ИИ», «платформа»), не ссылки на госпрограммы и не статус соисполнителей.

Единственный критерий состоятельности – прохождение пяти жестких фильтров аудита:

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

Артефакт: предъявлена ли работающая система с описанием охваченных потоков данных, а не набор слайдов и методичек.

Архитектура: замкнуты ли штатные операции на единую модель данных с формализованными интеграционными контрактами.

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

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

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