Почему проекты цифровых двойников терпят неудачу и как этого избежать

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-11

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

Automatically translated with AI from the original post. Read the English original

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

Ключевые выводы

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

Почему проекты цифровых двойников терпят неудачу: краткий ответ

Цифровой двойник — это поддерживаемое цифровое представление физического объекта, которое обновляется на основе наблюдений, например, по данным с оборудования почти в реальном времени. Важны слова «поддерживаемое» и «обновляется». Цифровой двойник — это не разовая модель и не трёхмерная модель или набор CAD-файлов производства. Это система, которая должна оставаться верной реальному производству, и именно здесь проекты и ломаются.

Несколько источников описывают один и тот же сценарий. В работе, представленной на Зимней конференции по имитационному моделированию 2023, Сиюань Чэнь и соавторы рассматривают проблемы цифровых двойников в обслуживании производственного оборудования. Они делят их на организационные, например, корпоративную культуру, высокие первоначальные затраты и страх потери работы, методологические, например, неясную выгоду и неясные бизнес-цели, и технические, например, сбор данных с устаревшего оборудования и совместимость. Исследование невелико: в нём участвовали шесть представителей отрасли, поэтому авторы отмечают, что выводы могут не отражать все компании.

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

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

Отказ 1: ни одно решение не опирается на двойника

Самая большая проблема в том, что никто не может сказать, для чего нужен цифровой двойник. «Мы хотим стать заводом Industry 4.0» — это направление, а не сценарий использования. В статье Chen перечислены неясные бизнес-цели и неясная выгода среди методологических проблем, а определение сценариев использования и получение поддержки руководства — среди барьеров.

Помогает простая проверка. Задайте спонсору один прямой вопрос: какое конкретное решение будет принято иначе, кем и к какой дате благодаря этому двойнику? Хорошие ответы конкретны. «Мы выберем между второй сменой и новым станком для линии 3 в марте». «Мы зададим размеры буферов до того, как будет построена новая компоновка». Слабый ответ: «мы будем лучше видеть происходящее».

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

Ошибка 2: низкое качество данных и слабая база данных

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

• Пропущенные данные. В данных о времени обработки, доступности ресурсов или записях о качестве есть пробелы. Simio советует начинать с оценок, основанных на опыте, для критичных параметров, фиксировать допущения и постепенно собирать реальные данные.
• Проблемы качества. Данные выглядят полными, но содержат выбросы, ошибки во времени или значения, которые противоречат друг другу в разных системах. Simio рекомендует правила валидации, автоматические проверки на выбросы и проверку экспертами по процессам.
• Проблемы интеграции. Данные находятся в ERP, MES и системах контроля качества, которые не обмениваются информацией. Simio советует поэтапную работу: от плановых выгрузок файлов к связям с базами данных и далее к полноценным интерфейсам.

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

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

Ошибка 3: никто не отвечает за данные или модель

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

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

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

Ошибка 4: слишком широкий охват для первого шага

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

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

Ошибка 5: проект воспринимается как ИТ-проект

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

Пример: проведите аудит одной линии, прежде чем масштабировать

Это иллюстративный расчёт с допущенными цифрами, а не измеренный случай. Завод планирует цифровой двойник для 12 линий. Ему нужно решить вопрос о размерах буферов на первой линии, поэтому спонсор сначала запрашивает аудит данных именно этой линии. Цифровому двойнику нужны 30 элементов данных на линию, например время цикла, причины и длительность остановок, структура заказов, укомплектованность персоналом и время переналадки.

Результат аудита линии 1:

• 11 элементов доступны и заслуживают доверия.
• 9 элементов существуют в двух системах, которые расходятся, например причины остановок в MES и в системе технического обслуживания.
• 6 элементов есть только на бумаге или в головах сменных мастеров.
• 4 элемента вообще не существуют.

Итак, 19 из 30 элементов требуют доработки, и только 11 из 30, что составляет около 37 процентов, готовы.

Широкий охват. Если завод предполагает похожие цифры для всех 12 линий, то 12 × 19 = 228 элементов требуют доработки. Допустим, как собственную плановую оценку, что один аналитик может исправить 5 элементов в неделю. Тогда работа с данными займёт 228 ÷ 5 = около 46 недель, почти год, до первого результата.

Узкий охват. Решение о буферах требует только 12 из 30 элементов, а аудит показывает, что у 5 из этих 12 есть проблемы. При 5 элементах в неделю это одна неделя работы с данными. Первый ответ появляется за несколько недель, и команда узнаёт, какие проблемы с данными вредят сильнее всего.

Ваши цифры будут другими, но аудит показывает, в какой ситуации вы находитесь.

Как избежать провала: пилот цифрового двойника в шесть шагов

1. Определите решение. Запишите, какое решение меняет цифровой двойник, кто его принимает и к какой дате.
2. Проведите аудит данных. Для каждого элемента, который нужен цифровому двойнику, найдите источник, владельца, частоту обновления и то, согласуются ли две системы. Посчитайте пробелы.
3. Назначьте владельцев. Один ответственный за каждую область данных и один за модель. Внесите их имена в план проекта.
4. Начните с узкого охвата. Одна линия или один шаг процесса, и только те элементы данных, которые нужны для решения.
5. Спланируйте обновления. Решите, как модель меняется, когда меняется завод, и кто запускает это изменение. Включите это в развёртывание, а не после него, и зафиксируйте рабочий процесс в документе.
6. Сверьте результат с решением. Через несколько недель проверьте, изменилось ли решение. Расширяйте охват только тогда, когда ответ положительный.

Распространённые ошибки

• Покупка платформы до определения сценария использования. Инструмент не подскажет, что решать.
• Доверие к данным только потому, что они существуют. Значение в базе данных — это не то же самое, что значение, которое корректно и актуально.
• Допущение расхождений между двумя системами. Цифровой двойник выберет одну из них и не сообщит вам об этом.
• Отсутствие владельца после запуска. Цифровой двойник без владельца устаревает после первого же изменения.
• Старт с охватом всего завода. Объём работы с данными растёт быстрее пользы, и инициативы с цифровыми двойниками теряют спонсора.
• Игнорирование производственного цеха. Если операторы и сотрудники технического обслуживания не доверяют двойнику, они им не воспользуются.

Как может помочь программное обеспечение

И аудит данных, и модель требуют единого, согласованного описания продуктов, шагов процесса и ресурсов. Polaris Designer от iFAKT — это модуль iFAKT Polaris, который строит граф знаний «продукт — процесс — ресурс» (PPR) как единый источник истины о продуктах, шагах процесса и ресурсах. Такое общее описание решает проблему конфликтующих данных, но не заменяет решение, владельцев и порядок обновлений. Программное обеспечение помогает, когда всё это уже на месте.

Следующий шаг

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