Чому проєкти цифрових двійників зазнають невдачі та як їх уникнути

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

Чому проєкти цифрових двійників зазнають невдачі: немає рішення, яке вони мають підтримувати, поганi дані, немає відповідальної особи та занадто широкий обсяг. Ознайомтеся з п'ятьма способами виправлення та практичним прикладом для керівників заводів.

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

Чому проєкти цифрових двійників зазнають невдачі, переважно є управлінським питанням, а не питанням програмного забезпечення. Типові причини: немає рішення, яке залежить від двійника, дані, яким ніхто не довіряє, відсутній відповідальний за модель і занадто широкий обсяг для першого кроку. Цей посібник призначений для керівників заводів, яких попросили спонсорувати цифровий двійник або які бачили, як такий проєкт застопорився. Ви дізнаєтеся про п'ять найпоширеніших точок відмови, практичний приклад із цифрами, порядок дій для їх уникнення та помилки, на які варто звернути увагу.

Головне

• Проєкти цифрових двійників рідко зазнають невдачі через програмне забезпечення; вони зазнають невдачі тому, що від двійника ніхто не залежить, дані не викликають довіри або ніхто не відповідає за модель.
• Перш ніж почати, визначте рішення, яке змінить двійник, хто його ухвалюватиме і до якого терміну. Якщо це неможливо, проєкт ще не готовий.
• Спочатку перевірте дані: для кожного елемента, який потрібен двійнику, знайдіть джерело, відповідального, ритм оновлення та те, чи узгоджуються дві системи.
• Двійник є живою моделлю: без процесу, який оновлює його щоразу, коли змінюється завод, він віддаляється від реальності, і люди перестають ним користуватися.
• Почніть з однієї лінії та одного рішення, доведіть цінність за кілька тижнів і лише потім розширюйте обсяг.

Чому проєкти цифрових двійників зазнають невдачі: коротка відповідь

Цифровий двійник — це підтримуване цифрове представлення фізичного ресурсу, яке оновлюється на основі спостережень, наприклад, із живими даними з верстатів майже в реальному часі. Важливі слова тут «підтримуване» та «оновлюване». Цифровий двійник — це не одноразова модель, і це не 3D-модель або набір CAD-файлів заводу. Це система, яка має залишатися достовірною щодо заводу, і саме тут проєкти й ламаються.

Кілька джерел описують однаковий патерн. Доповідь на Winter Simulation Conference 2023 за авторства Siyuan Chen та співавторів розглядає виклики цифрових двійників в обслуговуванні виробництва. Автори групують їх на організаційні, зокрема корпоративну культуру, високі початкові витрати та страх втрати роботи; методологічні, зокрема неочевидні вигоди та нечітко визначені бізнес-цілі; і технічні, зокрема збирання даних зі застарілих верстатів та сумісність. Дослідження невелике, за участі шести інтерв'юйованих представників галузі, тому автори зазначають, що їхні висновки можуть не відображати всі компанії.

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

На основі цих джерел і типової проєктної практики ми групуємо відмови в п'ять категорій. Це групування є нашим власним узагальненням, а не стандартом.

Відмова 1: від двійника ніхто не залежить

Найбільший виклик у тому, що ніхто не може сказати, для чого потрібен цифровий двійник. «Ми хочемо бути заводом Industry 4.0» — це напрямок, а не сценарій використання. У статті Chen перелічено нечіткі бізнес-цілі та нечітко окреслені вигоди як методологічні виклики, а серед бар'єрів названо визначення сценаріїв використання та отримання підтримки керівництва.

Допомагає простий тест. Поставте спонсору одне пряме запитання: яке конкретне рішення буде ухвалено інакше, ким і до якої дати саме завдяки цьому двійнику? Добрі відповіді конкретні. «Ми вибиратимемо між другою зміною та новим верстатом для лінії 3 у березні». «Ми задамо розміри буферів до того, як буде побудовано нову компоновку». Слабка відповідь — «ми матимемо кращу видимість».

Якщо відповідь розмита, у проєкту немає сигналу для зупинки. Він триватиме, доки не закінчиться бюджет, і тоді ніхто не зможе показати результат.

Помилка 2: погана якість даних і слабка основа даних

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

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

Informatica додає майстер-дані та основу даних. Без надійного реєстру активів, їхнього розташування, історії обслуговування та критичності двійник має числа, але мало контексту, а будь-яка функція ШІ або прогнозування поверх нього працює на слабкому шарі даних. У статті наголошується, що хибні дані можуть призвести до пропущених сповіщень про технічне обслуговування або помилкових замовлень запчастин.

Для заводу практичний вияв цієї проблеми простий. Чи фіксує система управління виробництвом ті самі причини зупинок, що й система технічного обслуговування? Чи використовують обидві системи один і той самий ідентифікатор верстата? Чи відповідають фізичні активи в системі управління технічним обслуговуванням лініям у MES і чи збігаються часи циклу в ERP з тим, що лінія насправді виконує? Якщо дві системи суперечать одна одній, цифровий двійник обере одну з них, а люди дізнаються пізніше, яка з них помилялася.

Помилка 3: ніхто не відповідає за дані чи модель

У цифрового двійника є два типи власників, і обидва часто відсутні. Кожен елемент даних потребує власника, який може підтвердити його коректність. Модель потребує власника, який оновлює її щоразу, коли змінюється завод.

Стаття Chen тут недвозначна. У ній сказано, що організаційні виклики потребують процесів, які забезпечують регулярні оновлення, і рекомендовано оновлювати модель щоразу, коли змінюється фізична система. Респонденти також наголошували на важливості людської експертизи для підтримки, розуміння та перевірки результатів двійника. Цифровий двійник, який ніхто не підтримує, — це знімок. Після першої зміни компоновки або першого нового продукту він більше не відповідає заводу, а оператори, які це помічають, перестають йому довіряти.

У тій самій статті зазначено, що більшість респондентів використовують цифрових двійників лише на етапі цифрової тіні. Повністю пов'язаний, самооновлюваний двійник — це довгострокова мета, а перша корисна версія часто є простішою моделлю з чітким власником.

Помилка 4: надто широкий обсяг для першого кроку

Наступна пастка — амбіції. Проєкт цифрового двійника, який стартує з формулювання «весь завод», має узгодити дані з кожної лінії, кожної системи та кожної команди, перш ніж щось показати. Кількість елементів даних зростає з кожною лінією, і разом із нею зростає кількість конфліктів.

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

Помилка 5: проєкт сприймають як ІТ-проєкт

Якщо модель створює лише ІТ-відділ або зовнішня команда, люди, які знають завод, долучаються пізно. Вони виявляють, що модель не враховує ручний крок, спільний інструмент чи неформальне правило. У статті 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 тиждень роботи з даними. Перша відповідь з'являється за кілька тижнів, і команда дізнається, які проблеми з даними завдають найбільшої шкоди.

Ваші цифри відрізнятимуться, але аудит покаже, в якій ситуації ви перебуваєте.

Як уникнути невдачі: пілотний проєкт цифрового двійника у шість кроків

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

Типові помилки

• Купівля платформи до визначення сценарію використання. Інструмент не скаже, що саме вирішувати.
• Довіра до даних лише через те, що вони існують. Значення в базі даних не те саме, що значення, яке є правильним і актуальним.
• Дозвіл двом системам суперечити одна одній. Цифровий двійник обере одну з них, і не скаже вам про це.
• Немає власника після запуску. Цифровий двійник без власника застаріває після першої зміни.
• Початок із цілого заводу. Робота з даними зростає швидше, ніж користь, і ініціативи з цифровими двійниками втрачають спонсора.
• Ігнорування цеху. Якщо оператори та працівники технічного обслуговування не довіряють двійнику, вони ним не користуватимуться.

Як може допомогти програмне забезпечення

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

Наступний крок

Оберіть одну лінію та одне рішення на наступний квартал і попросіть команду проаудіювати 10–20 елементів даних, які потрібні для цього рішення. Якщо аудит покаже, що більшість елементів не готові, ви дізнаєтеся, чому проєкти з цифровими двійниками зазвичай провалюються, ще до витрат бюджету, і знатимете, з чого почати.