Mengapa Proyek Digital Twin Gagal dan Cara Menghindarinya

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

Mengapa proyek digital twin gagal: tidak ada keputusan yang didukung, data yang buruk, tidak ada pemilik, dan cakupan yang terlalu luas. Lihat lima solusi dan contoh kasus untuk manajer pabrik.

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

Mengapa proyek digital twin gagal lebih banyak merupakan persoalan manajemen, bukan persoalan perangkat lunak. Penyebab yang umum meliputi tidak adanya keputusan yang bergantung pada twin, data yang tidak dipercaya siapa pun, tidak adanya pemilik untuk model, dan cakupan yang terlalu luas untuk langkah pertama. Panduan ini ditujukan bagi manajer pabrik yang diminta menjadi sponsor digital twin atau yang pernah melihat proyek semacam itu terhenti. Anda akan mempelajari lima titik kegagalan paling umum, contoh kasus dengan angka, rutinitas untuk menghindarinya, serta kesalahan yang perlu diwaspadai.

Poin Penting

• Proyek digital twin jarang gagal karena perangkat lunaknya; proyek gagal karena tidak ada keputusan yang bergantung pada twin, data tidak dipercaya, atau tidak ada yang memiliki model tersebut.
• Sebelum memulai, tentukan keputusan yang akan diubah oleh twin, siapa yang mengambilnya, dan kapan. Jika Anda belum bisa menjawabnya, proyek belum siap.
• Periksa data terlebih dahulu: untuk setiap item yang dibutuhkan twin, temukan sumbernya, pemiliknya, ritme pembaruannya, dan apakah dua sistem saling sepakat.
• Twin adalah model yang hidup: tanpa proses yang memperbaruinya ketika pabrik berubah, twin akan menyimpang dari kenyataan dan orang berhenti menggunakannya.
• Mulailah dengan satu lini dan satu keputusan, buktikan nilainya dalam hitungan minggu, lalu perluas cakupannya.

Mengapa proyek digital twin gagal: jawaban singkatnya

Digital twin adalah representasi digital yang dipelihara dari sumber daya fisik yang diperbarui berdasarkan observasi, misalnya dengan data langsung dari mesin secara hampir real-time. Kata kuncinya adalah "dipelihara" dan "diperbarui". Digital twin bukan model satu kali, dan bukan model 3D atau kumpulan file CAD pabrik. Ia adalah sistem yang harus tetap sesuai dengan kondisi pabrik, dan di situlah proyek sering kali runtuh.

Beberapa sumber menggambarkan pola yang sama. Sebuah makalah pada 2023 Winter Simulation Conference oleh Siyuan Chen dan rekan penulis meninjau tantangan digital twin dalam pemeliharaan manufaktur. Tantangan tersebut dikelompokkan menjadi tantangan organisasi, seperti budaya perusahaan, biaya awal yang tinggi, dan ketakutan akan kehilangan pekerjaan; tantangan metodologis, seperti manfaat dan tujuan bisnis yang tidak jelas; serta tantangan teknis, seperti akuisisi data dari mesin lama dan interoperabilitas. Studi ini berskala kecil, dengan enam narasumber dari industri, sehingga para penulis menyatakan temuannya mungkin tidak mewakili semua perusahaan.

Vendor perangkat lunak menyampaikan hal serupa dari sisi mereka. Simio, vendor simulasi, berargumen dalam postingan blog bahwa proyek lebih sering terhenti karena masalah data dibandingkan teknologi. Informatica, vendor manajemen data, menulis dalam artikel tentang fondasi data bahwa twin tanpa data tepercaya itu terbatas dan dapat menyesatkan. Keduanya menjual alat untuk masalah data, jadi bacalah sebagai satu sudut pandang.

Dari sumber-sumber ini dan dari praktik proyek yang umum, kami mengelompokkan kegagalan menjadi lima. Pengelompokan ini adalah ringkasan kami sendiri, bukan standar.

Kegagalan 1: tidak ada keputusan yang bergantung pada twin

Tantangan terbesarnya adalah tidak ada yang bisa menjelaskan untuk apa digital twin itu sebenarnya. "Kami ingin menjadi pabrik Industri 4.0" adalah sebuah arah, bukan sebuah kasus penggunaan. Makalah Chen mencantumkan tujuan bisnis yang tidak jelas dan manfaat yang tidak jelas sebagai tantangan metodologis, serta mencantumkan identifikasi kasus penggunaan dan perolehan komitmen manajemen sebagai hambatan.

Sebuah uji sederhana bisa membantu. Ajukan satu pertanyaan langsung kepada sponsor: keputusan spesifik apa yang akan diambil secara berbeda, oleh siapa, dan pada tanggal berapa, karena twin ini ada? Jawaban yang baik bersifat konkret. "Kami akan memilih antara shift kedua dan mesin baru untuk lini 3 pada Maret." "Kami akan menetapkan ukuran buffer sebelum tata letak baru dibangun." Jawaban yang lemah adalah "kami akan memiliki visibilitas yang lebih baik".

Jika jawabannya kabur, proyek tidak memiliki sinyal untuk berhenti. Proyek akan terus berjalan sampai anggarannya habis, dan setelah itu tidak ada yang bisa menunjukkan hasilnya.

Kegagalan 2: kualitas data yang buruk dan fondasi data yang lemah

Digital twin hanya sebaik datanya. Simio menyebutkan tiga masalah data, dan masalah tersebut sesuai dengan yang ditemukan di pabrik:

• Data yang hilang. Waktu proses, ketersediaan sumber daya, atau catatan kualitas memiliki celah. Simio menyarankan untuk memulai dengan estimasi berbasis pengalaman untuk parameter kritis, mencatat asumsi tersebut, dan mengumpulkan data nyata seiring waktu.
• Masalah kualitas. Data tampak lengkap tetapi mengandung nilai pencilan, kesalahan waktu, atau nilai yang saling bertentangan antar sistem. Simio menyarankan aturan validasi, pemeriksaan pencilan otomatis, dan peninjauan oleh pakar proses.
• Masalah integrasi. Data berada di ERP, MES, dan sistem kualitas yang tidak saling terhubung. Simio menyarankan pekerjaan dilakukan secara bertahap, mulai dari ekspor file terjadwal hingga tautan basis data dan antarmuka di kemudian hari.

Informatica menambahkan data master dan fondasi data. Tanpa catatan aset yang tepercaya, mencakup lokasi, riwayat layanan, dan tingkat kekritisannya, sebuah twin hanya memiliki angka tanpa konteks, dan fungsi AI atau prediktif apa pun yang dibangun di atasnya bekerja di atas lapisan data yang lemah. Artikel tersebut memperingatkan bahwa data yang salah dapat menyebabkan terlewatnya peringatan pemeliharaan atau pemesanan suku cadang yang keliru.

Bagi sebuah pabrik, bentuk praktis dari masalah ini sederhana. Apakah sistem eksekusi manufaktur mencatat alasan henti yang sama dengan sistem pemeliharaan? Apakah keduanya menggunakan pengenal mesin yang sama? Apakah aset fisik di sistem manajemen pemeliharaan sesuai dengan lini di MES, dan apakah waktu siklus di ERP sesuai dengan yang benar-benar dijalankan lini? Jika dua sistem tidak sepakat, digital twin akan memilih salah satunya, dan orang-orang baru akan mengetahui kemudian mana yang keliru.

Kegagalan 3: tidak ada yang memiliki data atau model

Sebuah digital twin memiliki dua jenis pemilik, dan keduanya sering kali tidak ada. Setiap item data membutuhkan pemilik yang dapat memastikan kebenarannya. Model membutuhkan pemilik yang memperbaruinya ketika pabrik berubah.

Makalah Chen cukup jelas dalam hal ini. Makalah tersebut menyatakan bahwa tantangan organisasi memerlukan proses yang memastikan pembaruan rutin, dan merekomendasikan pembaruan model setiap kali sistem fisik berubah. Narasumber juga menekankan pentingnya keahlian manusia dalam memelihara, memahami, dan memverifikasi hasil twin. Digital twin yang tidak dipelihara siapa pun hanyalah sebuah potret sesaat. Setelah perubahan tata letak atau produk baru pertama, twin tersebut tidak lagi sesuai dengan pabrik, dan operator yang menyadarinya berhenti mempercayainya.

Makalah yang sama mencatat bahwa sebagian besar responden hanya menggunakan digital twin pada tahap digital shadow. Twin yang sepenuhnya terhubung dan memperbarui dirinya sendiri adalah tujuan jangka panjang, dan versi pertama yang berguna sering kali berupa model yang lebih sederhana dengan pemilik yang jelas.

Kegagalan 4: cakupan terlalu luas untuk langkah pertama

Jebakan berikutnya adalah ambisi. Proyek digital twin yang dimulai dengan "seluruh pabrik" harus menyelaraskan data dari setiap lini, setiap sistem, dan setiap tim sebelum menampilkan sesuatu. Jumlah item data bertambah seiring setiap lini, dan jumlah konflik ikut bertambah.

Cakupan yang sempit, yaitu pilot digital twin pada satu lini, menempatkan model di hadapan pengguna nyata sejak dini. Satu lini, satu keputusan, dan satu kelompok pengguna sudah cukup untuk mengetahui apakah data tersebut dapat diandalkan dan apakah orang menggunakan jawabannya. Makalah Chen mencantumkan perolehan komitmen manajemen dan membangun kepercayaan sebagai hambatan, dan hasil awal yang cepat dan tepat membantu keduanya.

Kegagalan 5: proyek diperlakukan sebagai proyek TI

Jika TI atau tim eksternal membangun model sendirian, orang-orang yang memahami pabrik baru dilibatkan terlambat. Mereka lalu menemukan bahwa model mengabaikan langkah manual, alat bersama, atau aturan informal. Makalah Chen mencantumkan budaya perusahaan, masalah komunikasi, dan ketakutan akan kehilangan pekerjaan sebagai tantangan. Perlakukan proyek ini sebagai manajemen perubahan, dengan business case yang terukur dan dapat diperiksa oleh pabrik, serta libatkan operator, pemeliharaan, dan perencanaan untuk membantu menentukan apa yang ditampilkan model.

Contoh: audit satu lini sebelum diskalakan

Ini adalah perhitungan ilustratif dengan angka asumsi, bukan kasus yang telah diukur. Sebuah pabrik merencanakan digital twin untuk 12 lini. Pabrik ingin memutuskan ukuran buffer untuk lini pertama, sehingga sponsor meminta audit data untuk lini tersebut terlebih dahulu. Digital twin membutuhkan 30 item data per lini, seperti waktu siklus, alasan dan durasi henti, bauran pesanan, staf, dan waktu changeover.

Hasil audit untuk lini 1:

• 11 item tersedia dan terpercaya.
• 9 item ada di dua sistem yang saling bertentangan, misalnya alasan henti di MES dan di sistem pemeliharaan.
• 6 item hanya ada di atas kertas atau di kepala para kepala shift.
• 4 item sama sekali tidak ada.

Jadi 19 dari 30 item perlu dikerjakan, dan hanya 11 dari 30, atau sekitar 37 persen, yang siap.

Cakupan luas. Jika pabrik mengasumsikan angka serupa untuk seluruh 12 lini, maka 12 × 19 = 228 item perlu dikerjakan. Sebagai angka perencanaan kami sendiri, anggaplah satu analis dapat memperbaiki 5 item per minggu. Maka pekerjaan data memakan waktu 228 ÷ 5 = sekitar 46 minggu, hampir setahun, sebelum hasil pertama tersedia.

Cakupan sempit. Keputusan buffer hanya membutuhkan 12 dari 30 item, dan audit menunjukkan 5 dari 12 item tersebut bermasalah. Dengan 5 item per minggu, itu berarti 1 minggu pekerjaan data. Jawaban pertama tiba dalam hitungan minggu, dan tim mengetahui masalah data mana yang paling merugikan.

Angka Anda mungkin berbeda, tetapi audit menunjukkan Anda berada dalam kasus yang mana.

Cara menghindari kegagalan: pilot digital twin dalam enam langkah

1. Tentukan keputusannya. Tuliskan keputusan apa yang diubah oleh digital twin, siapa yang mengambilnya, dan pada tanggal berapa.
2. Audit data. Untuk setiap item yang dibutuhkan digital twin, temukan sumbernya, pemiliknya, ritme pembaruannya, dan apakah dua sistem saling sepakat. Hitung celahnya.
3. Tetapkan pemilik. Satu orang untuk setiap domain data dan satu orang untuk model. Cantumkan nama mereka dalam rencana proyek.
4. Mulai dari cakupan sempit. Satu lini atau satu langkah proses, dan hanya item data yang dibutuhkan keputusan.
5. Rencanakan pembaruan. Tentukan bagaimana model berubah saat pabrik berubah, dan siapa yang memicunya. Sertakan ini dalam penerapan, bukan setelahnya, dan tuliskan alurnya.
6. Tinjau terhadap keputusan. Setelah beberapa minggu, periksa apakah keputusan diambil secara berbeda. Perluas cakupan hanya ketika jawabannya ya.

Kesalahan umum

• Membeli platform sebelum menetapkan kasus penggunaan. Alat tidak memberi tahu Anda apa yang harus diputuskan.
• Mempercayai data hanya karena data itu ada. Sebuah nilai di basis data tidak sama dengan nilai yang benar dan mutakhir.
• Membiarkan dua sistem saling bertentangan. Digital twin akan memilih salah satunya tanpa memberi tahu Anda.
• Tidak ada pemilik setelah go-live. Digital twin tanpa pemilik akan usang setelah perubahan pertama.
• Memulai dari seluruh pabrik. Pekerjaan data tumbuh lebih cepat daripada manfaatnya, dan inisiatif digital twin kehilangan sponsornya.
• Mengabaikan lantai produksi. Jika operator dan staf pemeliharaan tidak memercayai twin, mereka tidak akan menggunakannya.

Bagaimana perangkat lunak dapat membantu

Audit data maupun model sama-sama membutuhkan deskripsi tunggal dan konsisten tentang produk, langkah proses, dan sumber daya. Polaris Designer dari iFAKT adalah modul iFAKT Polaris yang membangun knowledge graph product-process-resource (PPR) sebagai sumber kebenaran tunggal untuk produk, langkah proses, dan sumber daya. Deskripsi bersama seperti ini mengatasi masalah data yang saling bertentangan, tetapi tidak menggantikan keputusan, pemilik, atau rutinitas pembaruan. Perangkat lunak membantu setelah semua itu sudah ada.

Langkah berikutnya

Pilih satu lini dan satu keputusan untuk kuartal berikutnya, lalu minta tim Anda mengaudit 10 hingga 20 item data yang dibutuhkan keputusan tersebut. Jika audit menunjukkan bahwa sebagian besar item belum siap, Anda telah mengetahui mengapa proyek digital twin gagal sebelum menghabiskan anggaran, dan Anda tahu harus mulai dari mana.