デジタルツインを繰り返し使える意思決定プロセスにする方法

シナリオライブラリを維持する

シナリオライブラリとは、新しい意思決定のたびに再利用する、名前の付いたモデル実行の短いリストです。2〜3件のプロジェクトを経た段階で、次のものが含まれているべきです。

• ベースケース：通常の受注構成で、現在動いているとおりの工場
• 計画上想定する最大の需要と、最も厳しい製品構成によるピークケース
• ボトルネックでの故障、サプライヤーの遅れ、あるシフトでの班単位の欠勤といった外乱
• 立ち上がり：新しいラインや製品の最初の数週間（生産量が低く、停止が多い状態）
• 却下した案（名前を変えて復活しないよう、負けた理由とともに残す）

各シナリオには、名前、日付、責任者、そしてどの問いに答えるものかを示す1文を付けます。新しい検討では、古いベースケースを変更するのではなく、日付付きのベースケースをコピーして使います。そうすれば承認の際に、漠然とした「シミュレーション」の代わりに「3月のベースケース、故障シナリオ付き」を引用できます。

前提登録簿を維持する

前提登録簿とは、すべてのシナリオが使う入力をまとめた1つの共有リストです。財務部門がある数字を、生産部門が別の数字を、設計部門がさらに別の数字を挙げる会議に終止符を打ちます。以下の行は例示です。

仕事の大半をこなすのは3つの列です。根拠の列は、値が実測されたものか、サプライヤーから得たものか、推定にすぎないかを示します。責任者の列は、それが間違っていたときに答える人の名前を示し、使用先の列は、その行が変わったときに再実行すべきシナリオを挙げます。推定の行には、誰かがそれを検証する期日が必要です。範囲で記載することはモデルにも適しています。モデルの確率的シミュレーションは、各入力をそのばらつきの範囲内で変動させるからです。

案の比較と提示の方法を1つに統一する

再現性を確保するには、すべての意思決定に同じルールが必要です。すべての案がライブラリの同じシナリオにさらされ、結果は常に同じ指標で示されます。生産量、リードタイム、待ち時間、工程と車両の稼働率です。意思決定ページには、勝った案、その弱点、そして意思決定を見直す条件を明記します。

ルールが同じであれば、経営陣は今年の投資を昨年の投資と比較できます。比較のステップについては、どのシナリオももっともらしく見えるときに設備投資案を比較する方法で詳しく説明しています。

各投資をモデルと照らし合わせてレビューする

投資後のレビューでは、通常、予算とスケジュールを確認します。ラインが承認されたシナリオのとおりに動いているかを確認することはまれです。デジタルツインは、その隙間を埋められます。

承認が名前の付いたシナリオを参照しており、ラインの現在の生産量や搬送負荷が想定と異なっている場合は、レビューにモデルを使ってください。モデルを、実際に施工されたレイアウト、実際のシフト、実際のサイクルタイムで更新します。そのうえで承認されたシナリオを再実行し、比較します。計画が間違っていたのか、現場が計画と異なっているのか、それとも単に立ち上がりが遅いだけなのかが分かります。答えによって、取るべき行動は異なります。

レビューが調達や契約だけに関するものの場合、あるいは日付付きのベースラインが存在しない場合は、モデルを使わないでください。誰も承認していないモデルと現実を比べても、何も証明できません。

結果がどうであれ、次のプロジェクトが修正済みの値から始まるよう、前提登録簿を更新してください。

月次レビューと継続的改善にモデルを取り入れる

月次の生産レビューは、たいてい過去を振り返るものです。生産量、ダウンタイム、不良、コストです。そこに、先を見据える短いブロックを1つ加えてください。新製品、設備の移設、シフト体制の変更など、今後4〜8週間に予定されている変更を挙げます。それらの変更を、ベースモデルのコピー上で案として、ベースケースとストレスケースを1つずつ検証し、先月の実行結果と比較します。ベースモデル自体を更新するのは、変更が現場で実際に行われた後だけです。結果を比較できるよう、少なくとも1つのストレスケースは毎月同じものにしてください。

継続的改善も同じように進めます。チームがバッファを動かしたり、ピッキングルートを変えたり、作業を割り当て直したりする前に、そのアイデアをモデルで検証します。流れ全体が改善するのか、それともボトルネックが次の工程に移るだけなのか。モデルで失敗したアイデアは、決して現場に届きません。合格したアイデアは一度で実装されて記録に残り、その後ベースモデルが現場に合わせて更新されます。

これを実用的にしているのはスピードです。家具メーカーのレイアウト最適化プロジェクトでは、生産エリアのマッピングに数日かかった一方、その後のAIによる最適化は数日ではなく数秒で終わりました。モデルがいったんできれば、次の問いを投げかけるコストは小さくなります。

1四半期で立ち上げる

1. 過去で最も良かったプロジェクトから始める。 そのモデル、シナリオ、前提を、最初のライブラリと登録簿にします。
2. 責任者を指名する。 デジタルツインのモデルは誰が管理すべきか？で説明しているように、設計、生産、財務、そしてモデル管理責任者です。
3. 直近の2つの意思決定を加える。 それらのシナリオと前提を記録し、ライブラリに履歴を持たせます。
4. 1つの実際の意思決定に使う。 重要な意思決定を1つ選び、ルールの例外を認めないでください。
5. 月次の先読みブロックを加える。 生産レビューに組み込みます。

同じ考え方は設備データにも当てはまります。IoTの側面については、既存工場でIoTを繰り返し使える運用の仕組みにする方法をご覧ください。

よくある質問

デジタルツインにおけるシナリオライブラリとは何ですか？

ベースケース、ピーク、外乱、立ち上がりなど、新しい意思決定のたびに再利用する、名前と日付の付いたモデル実行のセットです。プロジェクトをまたいで結果を比較できる状態に保ちます。

前提登録簿には何を含めるべきですか？

各入力について、その値または範囲、その根拠、責任者、最終確認日、それを使っているシナリオです。推定値には印を付け、検証の期日を設定してください。

投資後のレビューでデジタルツインを使うべきなのはどんなときですか？

承認が名前の付いたシナリオに基づいており、ラインが現在、想定とは異なる成果を出しているときです。承認時の日付付きベースラインがなければ、モデルを使ってもあまり意味がありません。

このプロセスに設備のリアルタイムデータは必要ですか？

いいえ。ライブラリと登録簿は静的データで機能し、工場が変わったときにそれぞれの責任者が更新します。DBR77 IIoTのリアルタイムデータは後の段階です。モデルを毎月使うようになり、そうした更新の合間にも工場の動きに追従させたくなったときに取り入れます。

まとめ

今月中に、直近のシミュレーションプロジェクトのフォルダを開いてください。そのベースケース、サイクルタイム、ストレスケースを最初のライブラリと登録簿にコピーし、各値に実測か推定かの印を付け、推定の行にはすべて責任者と期日を設定してください。

出典

• DBR77、ケーススタディ：レイアウト最適化（本サイトの事例ページ）
• DBR77 Digital Twin、決定論的シミュレーションと確率的シミュレーションの比較