デジタルツイン導入プロジェクトの多くが失敗する理由と、その回避策

原因1：モデルの背後に意思決定がない

最もよくある出発点の目標は「デジタルツインが必要だ」というものです。これはツールの名前を挙げただけで、目的は空白のままです。支えるべき意思決定がなければ、どのデータが重要か、モデルがどこまでできれば十分かを誰も言えません。

実際に機能する目標は、意思決定、選択肢、期日の3つで構成されます。たとえば「3月末までに、新しい組立エリアの2つのレイアウトから、シフトあたりの生産量とフォークリフトの負荷に基づいて一つを選ぶ」。この一文があれば、チームは何をモデル化し、何を測り、いつ終えればよいかが分かります。

誰かがモデリングツールを開く前に、意思決定の一文を書いてください。誰も書けないなら、そのプロジェクトはまだ始める準備ができていません。

原因2：最初のプロジェクトとしては範囲が大きすぎる

2つ目の落とし穴は、工場全体を一度にモデル化しようとすることです。すべてのライン、すべての製品バリエーション、すべての例外、すべてのシステム連携。そうしたモデルが完成する頃には、本来支えるはずだった意思決定はすでに下されています。たいていは勘によってです。

最初の範囲として適切なのは、意思決定が関わるエリアと、そのエリアとリソースを共有するものです。2つのラインがフォークリフトやバッファを共有しているなら、両方をモデルに含めます。敷地の反対側にあり、それらと一切関わらない塗装工場は外しておけます。

範囲が小さくても、重要な意思決定を担えます。DBR77のある事例では、複数案の生産ラインのレイアウト分析に約1週間かかりました。範囲が一つの問いによって決められていたからです。手順、役割、所要期間は初めてのシミュレーションプロジェクトの進め方で解説しています。

ですから、一つのエリアと一つの意思決定から始め、次の意思決定で必要になったときにモデルを広げてください。

原因3：比較ではなく絵になっている

美しい3Dモデルを納品したものの、「どの案が優れているか」に答えられないプロジェクトがあります。フォークリフトは動いていますが、比較できる数字がありません。取締役会は生産量とコストについての答えを期待していたのに、受け取ったのは動画でした。

逆の間違いも同じくらいよく見られます。計画どおりの1つのシナリオだけを平均値で動かすモデルです。これは計画を検証するのではなく、追認するだけです。平均値は待ち行列を隠すため、固定のサイクルタイムを使う決定論的モデルでは、紙の上では機能するのに最初の繁忙週でつまずくラインが描かれてしまうことがあります。

役に立つモデルは、少なくとも2つの案を同じ指標で比較します。通常は現状と、1つか2つの変更案です。指標は、シフトあたりの生産数、主な工程の前での待ち時間、バッファの水準、フォークリフトや搬送車の稼働率などです。3DやVRは、その結果を人が理解する助けになります。

モデルを作る前に、比較する案と指標について合意し、3Dビューは結果が出たあとにそれを説明する手段として計画してください。

原因4：完璧なデータを待っている

多くのプロジェクトがデータの段階で止まります。チームが、モデルにはまず設備のリアルタイムデータと完全なマスターデータが必要だと判断します。システム連携のプロジェクトが膨らみ、意思決定の期限が過ぎてしまいます。

最初のモデルの多くは、リアルタイムデータなしで動きます。必要なのは、工程の順序、幅を持ったサイクルタイム、段取り替えと停止についての前提、搬送速度、シフトのルール、標準的な1週間の受注構成です。その大半はERP、工程表、CADのレイアウトにあります。残りはストップウォッチで計測できますし、最初は公称値でも構いません。最初の結果には、たいていチームが驚きます。モデルと現場の実際の生産量との差が、本当のボトルネックがどこにあるかを示すからです。

データが欠けている部分は、前提を書き出し、それが前提であることを明記したうえで、前提を動かしたときに結果が変わるかどうかを検証します。案の順位が変わらなければ、その欠落はこの意思決定にとって重要ではありません。順位が入れ替わるなら、どのデータを集めるべきかが正確に分かります。設備のリアルタイムデータ（たとえばDBR77 IIoT）は、こうした学びの次の段階です。モデルを定常的に使うようになり、工場の動きに追従させたくなったときに取り入れてください。

実務上のルールは、手元にあるデータから始め、すべての前提を明記し、明確な理由ができたときにリアルタイムデータを接続することです。

原因5：最初のプロジェクトの後、誰もモデルを担当していない

一つの問いにうまく答えたデジタルツインでも、失敗することがあります。最初のプロジェクトが終わり、モデルを作ったエンジニアは別の仕事に移り、数か月後には工場に新しい設備、新しいシフト体制、新製品が入っています。モデルが現場と合わなくなると誰も信頼しなくなり、誰も使わなくなります。

このゆっくりとしたずれが、デジタルツインを一度きりの検討に変えてしまいます。誰かがモデルを担当しなければなりません。現場で変更が行われるたびにベースモデルを更新し、前提の一覧を管理し、いつ見直しが必要かを判断する人です。エンジニアリング、生産、財務のそれぞれに役割があります。役割の分け方はデジタルツインのモデルは誰が所有すべきかで解説しています。

最初のプロジェクトを閉じる前に、モデルの担当者を名前で決め、更新のルールについて合意してください。

開始前の簡単なチェック

キックオフの場でこの表を使ってください。モデリングを始める前に、警告サインをすべて解消します。

よくある質問

デジタルツインのプロジェクトが失敗する最も多い理由は何ですか。

具体的な意思決定がないまま始めることです。目標が「この期日までにこれらの選択肢から選ぶ」ではなく「デジタルツインを持つ」になっていると、モデルには明確な範囲も、ゴールも、利用者もありません。

最初のデジタルツインのプロジェクトはどのくらいの規模にすべきですか。

一つの現実の意思決定に答えられる大きさで、それ以上にはしないことです。変更が起きるエリアと、それとフォークリフト、バッファ、人を共有するものをモデル化します。

失敗を避けるには設備のリアルタイムデータが必要ですか。

いいえ。リアルタイムデータを待つこと自体が、よくある失敗の原因です。最初のモデルの多くは、ERPのデータ、工程手順、CADのレイアウト、現場での計測で動かし、前提を明記しておけば十分です。

変更後もデジタルツインを工場の実態に合わせておくにはどうすればよいですか。

担当者を決め、前提の一覧を管理し、工場のどの変更があればベースモデルを更新するかを合意しておくことです。検討中の案はコピー上で試すため、ベースモデルは変わりません。そうしなければモデルは現場と合わなくなり、人々は信頼しなくなります。

まとめ

デジタルツインのプロジェクトがすでに計画されているなら、今週中に上のキックオフ用の表と照らし合わせてください。最も大きく左右するのは1行目です。選択肢と期日を含む意思決定の一文を誰も書けないなら、書ける人が出てくるまでモデリングの予算は保留にしてください。

出典

• DBR77, 事例：生産ラインの設計（本サイトの事例ページ）
• DBR77 Digital Twin, 決定論的シミュレーションと確率的シミュレーションの比較
• DBR77 Digital Twin, 活用事例