デジタルツインのモデルは誰が管理すべきか？

管理を4つの役割に分ける

各部門が、自分たちが最もよく知っているモデルの部分を管理します。

この分担は、工場がすでに動いている仕組みをそのまま反映しています。設計部門は構造に責任を持ち、生産部門は現場の数字に責任を持ち、財務部門は投資稟議書の言葉に責任を持ちます。結果に疑問が出たとき、誰に聞けばよいかを全員が分かっています。

データ接続はIT部門が担うことがよくありますが、バッファのルールやサイクルタイムがまだ正しいかどうかを知っていることはまれです。その判断こそ、上の管理者たちが担うものです。

モデル管理責任者：省略できない役割

3つの部門の管理者は、モデルのうち自分たちの担当部分が工場と一致していることを確かめます。モデル管理責任者は、ベースモデル、そのバージョン、シナリオを整理された状態に保ちます。その仕事は次のとおりです。

• モデルとその入力の日付付きバージョンを保管する、
• 工場が変わったら更新を実行する、
• 会議で参照できるようにシナリオに名前を付ける、
• 経営陣向けに結果の短い要約を書く、
• 古い結果が最新のものとして提示されるのを止める。

最後の仕事には、時間に加えて権限が必要です。モデル管理責任者が「この結果はライン変更前のものなので、再実行が必要です」と言えなければ、古い数字が新しい意思決定に出続けることになります。

モデル管理責任者には、確保された時間も必要です。例示的な目安として、プロジェクトの合間は週に半日、プロジェクト中はそれ以上を見込んでください。「時間があるときに」モデルを扱うボランティアでは、管理体制が失敗する最も一般的な原因になります。

モデルを更新すべきタイミング

選択肢を検証しても、ベースモデルは変わりません。各選択肢は、そのコピー上のシナリオとして動かすからです。ベースモデルを更新するのは、どの案が勝つかを変えうる形で工場そのものが変わったときです。典型的なトリガーは次のとおりです。

• ボトルネックが移動した、または2つの工程に分かれた、
• 設備、ロボット、自律搬送車が追加、撤去、または入れ替えられた、
• 工程順序、ロットサイズ、ピッキングのルールが変わった、
• シフト体制や人員配置のモデルが変わった、
• 製品構成や受注量が、モデル内の範囲から外れた、
• 投資プロジェクトによって、搬送ルート、バッファ、保管が変わった。

トリガーが1つあれば、更新を予定するのに十分です。ただし、すべての変更で全面的な再構築が必要なわけではありません。工程の名称変更ならメモで足ります。1つのサイクルタイムがその範囲内で動いただけなら、簡単な再実行で済みます。新しい工程順序や新しい設備には、構造の更新と新しいベースラインが必要です。大規模な投資の後は、完成した工場に合わせてベースモデル全体を更新してください。そのバージョンが次の意思決定の出発点になります。

モデルの信頼性を保つ変更ルール

変更がいくつかのシンプルなルールに従っていれば、管理体制は機能します。

1. すべての変更に作成者と日付を残す。 サイクルタイムが変わったら、誰が、いつ、なぜ変えたのかを記録に残します。
2. 直近の正しいバージョンを保管する。 更新の前に、現在のモデルとその結果を、日付と、それが裏付けた意思決定とともに保存します。
3. 承認会議の前に、生産部門が現場データを承認する。 生産部門の管理者の確認なしに、サイクルタイムやシフトのルールを投資ケースに入れてはいけません。
4. 更新のたびに短いメモで締めくくる。 何が変わったか、どの結果が動いたか、どの過去の意思決定を見直すべきかを記します。
5. 工場の変更にはモデルの確認を含める。 変更要求で設備、バッファ、ルートが動くなら、モデルによる変更前後の比較を添付します。

これらのルールは事務作業のように聞こえます。実際には、どれも数分で済みます。そして、どの数字が正しいかを言い争う会議の時間を何時間も節約してくれます。

データを維持するのは誰か：手作業か、センサーか

管理体制は、モデルがどのようにデータを得るかにも左右されます。静的データの場合、生産部門の管理者が更新されたサイクルタイム、停止、シフトを提供し、モデル管理責任者がそれを入力します。範囲を求めてください。モデルの確率的シミュレーションは、各値のばらつきを使って動くからです。DBR77 IIoTによる設備のリアルタイムデータは次の段階です。モデルを毎週使うようになり、そうした更新の合間にも工場の動きに追従させたくなったときに取り入れます。それでも誰かがデータ連携に責任を持つ必要があります。欠けた信号を直し、データが遅れたときにモデルが何を使うかを決めることです。それぞれの方法がどんな場合に適しているかは、デジタルツインをリアルタイムデータに接続すべきときで説明しています。

管理体制が機能しているサイン

分担が機能しているかどうかは、数か月以内に分かります。

• 投資申請が「シミュレーション」ではなく、名前と日付の付いたシナリオを参照している。
• 生産部門が、モデルの変更を、経営会議のスライドに載る前に短いメモで知る。
• 財務部門が、稟議書に記載された範囲を、自分たちが合意したものとして認識している。
• 結果に驚いた人が、誰に連絡すればよいかを知っている。

逆のサインも同じくらい明確です。別々のノートPCにある2つのバージョンのモデル、誰もたどれない数字、新しい設備が据え付けられた後にそれを知るモデル管理責任者です。管理体制が機能したら、次のステップは、シナリオライブラリと共有の前提登録簿を使って、プロジェクトをまたいでモデルを再利用することです。これについてはデジタルツインを繰り返し使える意思決定プロセスにする方法で説明しています。

よくある質問

デジタルツインはIT部門が管理すべきですか？

通常、主たる管理者としてはお勧めしません。IT部門はデータ接続とインフラを担えますが、モデルの中身は設計、生産、財務の各部門のものであり、モデル管理責任者がそれを取りまとめます。

外部パートナーがモデルを管理してもよいですか？

外部パートナーはモデルを構築し、更新を支援できます。しかし、現場データ、範囲、公表に関する判断は工場の中にとどめるべきです。そうでなければ、契約が終わるとモデルも去ってしまいます。

モデルはどのくらいの頻度で更新すべきですか？

新しい設備、ボトルネックの移動、新しいシフト体制など、工場が変わったときにベースモデルを更新し、重要な意思決定の前には、モデルがまだ現場と一致しているかを確認してください。検証する選択肢はコピー上で動かすため、ベースモデルはそのまま残ります。四半期ごとなど、決まった日程でのレビューを設けると、誰も報告しなかった変化を拾えます。

モデル管理責任者が退職したらどうなりますか？

上で述べたように、バージョン、シナリオ名、変更メモが保管されていれば、新しい責任者が数日で引き継げます。知識が1人の頭の中にしかなければ、モデルもたいていその人とともに去ってしまいます。

まとめ

まずモデル管理責任者を指名し、その人がモデルに使える時間を書き出してください。そのうえで、設計、生産、財務の担当者に一度集まってもらい、役割の表からそれぞれの行を引き受けてもらい、次のプロジェクトが始まる前に更新のトリガーについて合意してください。

出典

• DBR77 Digital Twin、決定論的シミュレーションと確率的シミュレーションの比較