ERP・MESデータによるリアルタイムのバリューストリーム監視

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

リアルタイムのバリューストリームは、ERPとMESのライブデータから、リードタイム、待ち時間、仕掛品を表示します。各システムが提供するデータ、必要な鮮度、構築方法を解説します。

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

リアルタイムのバリューストリームとは、リードタイム、待ち時間、仕掛品などの数値を、ストップウォッチを使った一度限りの現場調査ではなく、ライブのERPとMESのデータから得るバリューストリームマップです。本記事は、次の定例のマッピングワークショップを待たずに、製品ファミリーの現状を把握したい工場長を対象としています。どのシステムがどのデータを提供するか、データはどの程度新しい必要があるか、最初のバージョンをどう構築するか、そして架空のタイムスタンプを使った具体例を解説します。

重要なポイント

• リアルタイムのバリューストリームは、リードタイム、待ち時間、仕掛品をシステムのライブデータから更新します。そのため、マップが壁に貼られたまま古くなることはありません。
• ERPは受注、工程表、在庫、コストを受注単位で提供します。MESは各工程で何が起きたかを、タイムスタンプ、数量、停止時間とともに提供します。
• データに求められる鮮度は、意思決定の内容によって異なります。払い出しには数分、日次レビューには毎日、傾向の把握には毎週が目安です。
• 各工程の引き渡し、開始、終了の時刻が分かれば、受注ごとに待ち時間、加工時間、リードタイムを計算するのに十分です。
• 記録の遅れや手入力は、ライブのマップを誤らせます。数値を信頼する前に、現場の実態と照合してください。

リアルタイムのバリューストリームとは何ですか。

Lean Enterprise Institute（LEI）は、バリューストリームマッピングを、製品がバリューストリームを進む間の、モノと情報の流れを可視化して理解する手法と定義しています。紙のマップは一時点のスナップショットです。描いた日には有効ですが、その後リードタイムは変化していきます。

リアルタイムのバリューストリーム（ライブのバリューストリームマップや、複数のバリューストリームを横断して見るビューと呼ばれることもあります）は、同じ全体像を最新の状態に保ちます。工程のボックスとタイムラインは生産データで埋められるため、待ち行列の増加、受注の滞留、在庫の動きを確認できます。データがミリ秒単位で届く必要はありません。そのデータを使って判断したい内容に対して、十分に新しければ足ります。

これはデータ駆動型のバリューストリームです。マップはリーンのツールであり続け、データがストップウォッチの役割を担います。チームに取って代わるものではありません。現場を歩いて流れを確認し、原因を問い、何を変えるかを決めるのは、今も人の役割です。

従来の現状マップとは、どのように違いますか。

従来の現状のバリューストリームマップは、部門横断のチームがワークショップで描きます。チームは工程を実際に歩き、サイクルタイム、リードタイム、在庫を手作業で記録し、モノと情報の流れを図にします。その後、将来の状態のマップを描き、改善を計画します。これはリーン生産方式の中核であり、共通理解を築くうえで、今後もこの形を維持すべきです。

ライブ版は、もう1つの層を加えるものです。チームは現状と将来の状態を引き続き描きますが、現状マップの数値はデータから更新されます。リアルタイムのビューでは、バリューストリーム同士を比較し、変更後にボトルネックがどこへ移動したかを追い、ワークショップの合間にも改善の余地を特定できます。すべての変更が数値に表れるため、継続的改善を支えます。効果は次のワークショップを待たず数日以内に見えるため、業務の流れを段階的に最適化する助けにもなります。ライブのデータは、現場でより良い問いを投げかけるために使ってください。現場に足を運ぶことの代わりに使ってはいけません。

どのデータがERPから来て、どのデータがMESから来るのか？

通常、データは2種類のシステムに保持されます。ReliaMagの独立した編集記事MES versus ERPでは、ERPは事業レベルで動作し、何を、いつ、いくらのコストで製造するかに答えるとされています。時間、日、週、月の単位で、受注と作業指示のレベルのデータを扱います。MES（製造実行システム）は、計画どおりに正しく製造されているかに答えます。秒と分の単位で、工程、サイクル、個品のレベルのデータを扱います。ERPは作業指示をMESに引き渡し、MESが実績をERPに報告します。

MESベンダーであるFabricoのISA-95に関するページは、同じ分担をレベルで説明しています。ERPは事業計画を担当するレベル4、MESは製造オペレーションを担当するレベル3です。また、事業レベルにはセンサーの測定値を大量に渡すのではなく、要約を渡すべきだとも述べています。

バリューストリームでは、次のように分けると実務的です：

• ERPから: 受注、納期、工程順序（ルーティング）、部品表、在庫金額、顧客データ、コスト。
• MESから: 各工程の開始と終了、良品数、スクラップ、手直し、ダウンタイムの理由、ステーションで消費された材料、オーダーの現在位置。
• 品質記録から: 検査結果と返品。
• 倉庫から: 入庫と出荷のイベント。

製造実行システムは、作業指示と工程に対して生産活動を記録する現場向けのソフトウェアです。これがないと、作業時間は手作業で記録され、遅れて、またはまとめて記録されることが多くなります。それでマップが役に立たなくなるわけではありませんが、信頼できる範囲は限られます。

タイムスタンプから何を計算できるか？

工程ごとに4つのタイムスタンプがあれば、ほとんどのフロー指標には十分です。作業指示のリリース、工程の開始、工程の終了、出荷です。これらから次を計算できます：

• リードタイム（受注ごと）: リリースから出荷まで。
• 処理時間（工程ごと）: 開始から終了まで。
• 待ち時間（工程の前）: 前工程の終了から次工程の開始まで。
• 仕掛在庫: 工程ごとの、リリース済みでまだ出荷されていない受注の件数。
• 付加価値率: 近似値として、処理時間をリードタイムで割った値。

MESの数量とスクラップからは、工程ごとの一発良品率が得られます。ERPの在庫からは在庫日数が得られます。

データの鮮度はどの程度必要か？

更新頻度は意思決定に従います。以下は私の経験則であり、標準ではありません：

• 分単位: 配台と現場での対応。例えば機械が停止した場合です。
• シフトごと、または日次: 前日のフローを確認する日次ボードとティア会議。
• 週次: リードタイム、納期、在庫の推移を確認するストリームレビュー。
• 月次または四半期: マップの描き直しと年間計画。

すべてのバリューストリームを最速の頻度にする必要はありません。データは速くするほど構築と維持のコストが上がり、週次の意思決定には分単位のフィードは必要ないからです。

最初のバージョンはどう作るか？

1. 製品ファミリーを1つ選び、5つの指標を追跡します。ストリームのプロセスマップ上で扱う指標は、リードタイム、工程ごとの待ち時間、仕掛在庫、納期遵守率、一発良品率です。
2. 必要なイベントを列挙し、それぞれをどのシステムが記録するかを確認します。各指標の計算式を書きます。
3. 記録の運用を確認します。現場を歩き、システム上の10件の受注と実際に起きたことを比較します。最も大きなずれから修正します。
4. データを抽出します。日次ファイルまたはデータベースのビューから始めます。最初のテストで複雑なインターフェースを作る必要はありません。
5. マップに表示します。データからプロセスのボックスとタイムラインを埋め、最も大きな待ち行列に印を付けます。
6. 週次で確認します。数値がチームの見ている状況と一致するかを確認し、ルールを調整します。
7. 最初のファミリーが機能したら、他のファミリーへ段階的に拡張します。

例：1件の受注、架空のタイムスタンプ

この例は架空のものです。時刻は実在の工場のものではなく、夜間や週末を含む暦時間です。

オーダー1042は月曜日の08:00にリリースされます。工程10は月曜日の14:00から16:00まで、工程20は水曜日の08:00から11:00まで、工程30は木曜日の10:00から12:00まで実行され、オーダーは金曜日の10:00に出荷されます。

リードタイムは98時間です。処理時間は2+3+2で7時間となるため、付加価値を生む割合は7÷98、約7パーセントです。待ち時間は、工程10の前が6時間、工程10と工程20の間が40時間、工程20と工程30の間が23時間、工程30の終了から出荷までが22時間です。合計は91時間で、処理時間の7時間と合わせると98時間になります。

最も長い待ち時間は40時間で、工程20の前にあります。同じパターンが多くのオーダーで見られる場合、チームはその工程を確認します。段取り替え、ロットサイズ、不足している工具、あるいは作業を一括で投入するルールなどが原因として考えられます。ライブマップは場所を示し、原因は現場の担当者が突き止めます。

よくある間違い

• 現場を確認せずに数値を信頼すること。 入力が遅れると、待ち行列は実態とかけ離れたものになります。
• 目的がないままリアルタイム性を追求すること。 更新頻度は、どの意思決定に使うかで選んでください。
• すべてのバリューストリームから同時に始めること。 1つのストリームでデータの問題を学び、複数のバリューストリームを同時に扱うと、問題が見えなくなります。
• 平均値だけを測定すること。 最も長いオーダーに、本当の問題が表れています。
• 定義より先に画面を作ること。 まず計算式と担当者を明確にしてください。
• 定例の運用を省くこと。 ライブ画面は、週次レビューやアクションリストの代わりにはなりません。

ソフトウェアで実現できること

ライブマップには、ストリームのモデルと、ERPやMESのデータとの接続が必要です。スプレッドシートで作成するのはパイロットでは有効ですが、製品ファミリーが増えると負担が大きくなります。iFAKTのPolaris VSMは、データに基づくバリューストリームマッピングのためのiFAKT Polarisのモジュールです。資材と情報の流れを共同でモデル化し、ムダやボトルネックを可視化します。まず1つの製品ファミリーで、データ接続をテストしてください。

次のステップ

リアルタイムのバリューストリームは、1つの製品ファミリーについて信頼できるタイムスタンプを用意することから始まります。今週中に、ERPやMESの10件のオーダーと現場で実際に起きたことを比較し、何かを構築する前に、最も大きなずれを書き出してください。