バリューストリームマッピングはライブなデータモデルになりうるか?

バリューストリームマッピングは、リーン生産において、材料・情報・意思決定が生産システム内をどのように流れるかを理解するための最も有用なツールの一つとなってきました。しかし、従来のバリューストリームマッピングには根本的な限界があります。

工場は変化し続けます。しかし、マップは変わりません。

生産、計画、品質、保全、サプライチェーン、オペレーションの各部門を同じワークショップに集めることができます。サイクルタイム、待ち行列、ロットサイズ、引き継ぎ、待ち時間、情報の流れ、ボトルネックをマッピングできます。ワークショップの最後には、全員が生産システムの仕組みについて同じ全体像を共有できるかもしれません。

しかし、現実は変わります。

サプライヤーの納品が遅れる。顧客が緊急の注文を入れる。設備が停止する。品質問題でロットが保留になる。保全によって生産から設備が外される。段取り替えが想定より長引く。資材が間違った場所で待機する。

壁に貼られたバリューストリームマップは、昨日の工場を描いたままなのです。

では、バリューストリームマップが、それ以上のものになれるとしたらどうでしょうか。

今回のエピソードでは、バリューストリームマッピングが、リーン生産の静的な文書から、ERP、MES、品質、保全、設備、現場データと接続された、リアルタイムの製造データモデルへと進化しうる姿を探ります。

目指すのは、単にバリューストリームマップをデジタル化することではありません。生産が実際にどのように振る舞っているかを継続的に反映するモデルを作ることです。

静的なバリューストリームマッピングの問題点

従来のバリューストリームマッピングは、生産システムの重要なスナップショットを捉えます。製品を生産するために必要な工程の順序を理解するのに役立ちますが、その価値は、箱と矢印を描くことをはるかに超えています。

バリューストリームマップは、加工時間、待ち時間、待ち行列、在庫、ロットサイズ、段取り替え、情報の流れ、補充の信号、生産管理のルール、組織の異なる部門間の引き継ぎを記述できます。

そのため、バリューストリームマッピングは、流れを理解するうえで非常に有用です。

しかし、生産は動的です。

ワークショップ中に捉えられた状況は、数日後にはすでに異なっているかもしれません。需要は変わります。資源は利用できなくなります。注文には異なる優先度が与えられます。品質問題が手直しを生みます。資材は遅れて届きます。生産計画は変更されます。実際のサイクルタイムは、計画上の前提とは異なります。

これらの変化は生産の実際の流れに影響しますが、通常はバリューストリームマップに自動的には反映されません。

ここで、現代の製造業にとって興味深い問いが生まれます。バリューストリームマッピングは、工場の継続的に更新されるモデルになれるのでしょうか。

バリューストリームマップからリアルタイムデータモデルへ

リアルタイムのバリューストリームモデルは、従来のバリューストリームマップを画面に映し出すだけのものとは根本的に異なります。

図をデジタル化することは比較的容易です。しかし、注文、工程、資源、資材、制約、イベント、生産状態の間の関係を理解するモデルを作ることは、はるかに困難です。

リアルタイムの製造モデルは、次のような問いに答える必要があります。

• 注文は今どこにあるのか？
• 最後に完了した工程はどれか？
• 次に何が起こるべきか？
• 必要な資源はどれか？
• その資源は実際に利用可能か？
• 資材は待機しているか？
• 品質が生産を止めているか？
• 保全によって利用可能な能力が減っているか？
• 注文は物理的な制約で待っているのか、それとも情報の遅れで待っているのか？

そして最も重要なのは次の問いです。

生産の現在の状態を証明する根拠は何か？

これは、バリューストリームマッピングを文書化から、オペレーショナル・インテリジェンスへと押し上げるものです。

1つの注文、多くの製造システム

受注生産の製造環境を考えてみましょう。

顧客の注文が、要求納期とともに事業に入ってきます。ERPは受注を作成し、生産要件を生成し、資材の利用可能性を確認し、想定される工程の順序を示すルーティング情報を提供します。

しかし、ERPが提供するのは全体像の一部にすぎません。

工場の現場では、製造実行システム（MES）が作業を払い出し、作業者の実績確認を記録し、生産の進捗を追跡し、シリアル番号やロット情報を管理するかもしれません。

設備システムは、別の視点を提供します。マシニングセンタは、稼働中、停止、異常、段取り中のいずれであるかを報告するかもしれません。炉は温度情報やサイクル完了イベントを提供するかもしれません。試験設備は合格・不合格の結果を生成するかもしれません。

産業用ゲートウェイ、ヒストリアン、PLC、IoTシステムは、さらに追加の運用信号を収集するかもしれません。

品質システムは、もう一つの層を加えます。検査結果によって資材が保留になるかもしれません。不適合が手直しを引き起こすかもしれません。品質の払い出しは、物理的な検査が終わってから数時間後に行われることもあります。

保全システムも、実際の生産計画に影響します。計画システム上では設備が利用可能に見えても、予定保全によって数時間使えないことがあります。

それぞれのシステムには価値のある情報が含まれています。しかし、どのシステム単独でも、生産の流れ全体を正確に記述できるとは限りません。

リードタイムは実際にどこへ消えたのか？

注文が遅れて出荷されたとします。

ERPは注文が作成された日を知っています。ERPは計画上の納期も知っています。MESは個々の工程がいつ実績確認されたかを知っています。設備データは、設備がいつ稼働していたかを示すかもしれません。品質システムは、検査がいつ行われたかを知っています。保全システムは、資源がいつ利用できなかったかを知っています。

しかし、計画担当者はもっと単純な問いを立てます。

なぜこの注文は遅れたのか？

リードタイムは実際にどこへ消えたのか？

機械加工の後で注文が待っていたのかもしれません。資材は物理的には準備できていたのに、運搬が行われなかったのかもしれません。検査は終わっていたのに、品質の払い出しが数時間後になったのかもしれません。設備には能力があったのに、必要な資材が別の場所で待っていたのかもしれません。

上流で仕事を流しすぎたため、本当の制約の前に待ち行列ができていたのかもしれません。あるいは、注文が現場に入った時点で、生産計画がすでに非現実的だったのかもしれません。

これらの問いに答えるために必要なデータは、すでに存在しているかもしれません。問題は、それが複数のシステムに分散していることです。

ERPのデータは、生産の現実と同じではない

ERPシステムは製造業にとって不可欠です。受注、資材、ルーティング、要件、在庫、購買、その他多くの業務プロセスを管理します。

しかし、ERPのルーティングは、生産がどのように行われる予定かを記述するものです。現在の工場の現場で何が物理的に起きているかを、自動的に記述するわけではありません。

この違いは、生産を最適化しようとするときに決定的になります。

生産計画では、注文が次の工程に進めると書かれているかもしれません。しかし工場の現場では、まったく異なる状況かもしれません。

• 設備が利用できない
• 資材がまだ届いていない
• 作業者がいない
• 品質がロットを止めている
• 前工程が想定より長くかかった
• 別の緊急注文がすでにその資源を占有している

計画上の生産モデルと実際の生産システムは、すぐに乖離しうるのです。リアルタイムのバリューストリームモデルは、その差を明らかにするのに役立つかもしれません。

なぜMESだけでは十分ではないのか

MESは、ERPよりもはるかに深い生産の可視化を提供します。作業指示、工程、実績確認、生産の進捗、トレーサビリティ、現場の実行を追跡できます。

しかし、MESもまた製造環境の一部しか表しません。

生産上の判断は、MESの外に保存された情報に依存することがあります。

• 品質システム
• 保全システム
• 倉庫管理システム
• 産業用IoTプラットフォーム
• 設備ヒストリアン
• 計画システム
• スケジューリングシステム
• ERP
• 作業者の入力
• 搬送システム

スプレッドシートにさえ、生産に影響する運用情報が含まれていることがあります。

そのため、リアルタイムの製造モデルには、単なる別のダッシュボードではなく、これらのシステム同士の関係性が必要なのです。

リアルタイムダッシュボードはリアルタイムのバリューストリームではない

多くのデジタル製造プロジェクトは、リアルタイムの可視化に焦点を当てています。設備の状態が収集され、生産データがレイクハウスに取り込まれ、ダッシュボードに未完了の注文が表示され、Power BIでKPIが可視化されます。管理者はより新しい情報を受け取れるようになります。

これは非常に価値のあることです。しかし、リアルタイムのデータだけでは、