ある1日の数字を追ってみる
抽象論では理解しにくいので、実際の数字で追います。設定は次のとおりです。
- 製品Xの製造指図：計画数 1,000個
- 工程は3つ：切断 → 加工 → 検査
- 部品Aを1個あたり1個消費。部品Aの投入は切断工程で行う
- ERPへの実績連携は「完成品の入庫報告」時に、標準BOMに基づくバックフラッシュ（自動消費計上）で行う
8時から17時までの動きです。
| 時刻 | 現場で起きたこと | MESのWIP | ERPの仕掛在庫 | ERPの部品A在庫 |
|---|---|---|---|---|
| 08:00 | 指図発行、部品A 1,000個を出庫 | 0 | 0 | −1,000 |
| 10:00 | 切断400個完了 | 400（切断済） | 0 | 変化なし |
| 12:00 | 加工300個完了、20個を不良判定 | 380 | 0 | 変化なし |
| 15:00 | 検査250個合格、完成品倉庫へ | 130 + 完成250 | 0 | 変化なし |
| 15:05 | 完成250個をERPへ入庫報告 | 130 | 0 | −250をバックフラッシュ |
| 17:00 | 作業終了。ライン上に130個残 | 130 | 0 | 差引 −1,250 |
17時時点で、MESは仕掛130個を認識し、ERPは仕掛0を認識しています。部品Aは1,000個出庫したのに、消費計上は250個分しかされていません。どちらも「正しく」動いています。
この状態が翌朝の会議で「システムが合っていない」と報告され、原因調査に人が張り付く、というのが典型的な流れです。しかし調査すべきはバグではなく、どこに、いくつ、どういう名目で在庫が滞留しているかという設計上の合意です。
ずれが生まれる5つの構造的な理由
上の例に限らず、MESとERPの仕掛がずれる原因は次の5つに分類できます。バグはこの5つを潰したあとに疑うもので、順序を逆にすると調査が長引きます。
理由1：報告タイミングの差（最大の要因）。 ERPは報告を受けた瞬間しか在庫を動かしません。工程間の滞留は、報告と報告のあいだに存在します。
理由2：バックフラッシュの前提と実消費の差。 バックフラッシュは標準BOMの数量で消費を計上します。実際には歩留まりの変動、端材、追加投入があり、標準どおりには減りません。この差は、原価計算では「数量差異」として扱われますが、リアルタイムの在庫としては合いません。
理由3：不良品と再作業品の扱い。 不良判定した20個は、廃棄なのか、再作業待ちなのか、判定保留なのかで在庫上の意味が違います。MESは「不良ステータスの仕掛」として持ちますが、ERP側に対応する在庫区分がないケースが多く、ここが差の常連です。
理由4：単位と丸め。 MESが「枚」、ERPが「kg」で持っている、あるいはMESが小数第2位まで、ERPが整数で持っている場合、変換のたびに端数が発生します。年間で見ると無視できない量になります。
理由5：切り戻し・訂正の非対称。 MES側で実績を訂正したとき、ERP側へ取消と再送が飛ぶか、差分だけが飛ぶか、あるいは何も飛ばず翌日の棚卸で調整されるか。ここが設計されていないシステムは非常に多く、訂正のたびに差が積み上がります。
設計で決めること：どこで、どの粒度で、いつ返すか
上の5つを踏まえると、決めるべきは3つに絞られます。これは製品選定ではなく、自社の会計・生産管理部門との合意事項です。
決め事1：消費計上をバックフラッシュにするか実消費にするか。
| 方式 | 消費が計上される時点 | 精度 | 現場負荷 | 向く条件 |
|---|---|---|---|---|
| 完成時バックフラッシュ | 完成報告時に標準BOM分を一括消費 | 低い。歩留まり差が残る | ほぼゼロ | 工程が短く、歩留まりが安定している量産 |
| 工程バックフラッシュ | 各工程の完了報告時に、その工程分を消費 | 中。滞留が見える | 小さい | 工程数が多く、リードタイムが長い |
| 実消費（投入実績入力） | 材料をスキャンして投入した時点 | 高い。ロットまで一致 | 大きい。読み取り運用が必須 | 高価材料、規制産業、系譜が必要な工程 |
3方式のどれかを全社一律にする必要はありません。高価材料と規制対象材料だけ実消費、残りはバックフラッシュというハイブリッドが現実的な着地点です。ただし品目マスタ側に「消費方式」の属性を持たせておかないと、後から切り替えられません。
決め事2：ERPへ返す粒度。 指図単位か、工程単位か、ロット単位か。細かく返すほどERP側のトランザクション量が増え、ERPの夜間バッチが伸びます。1日数万件のトランザクションを工程単位でERPへ送って、ERPの月次締めが終わらなくなった例は実際にあります。粒度は性能要件と一体で決めます。詳細はMES-ERP連携の設計で扱う論点と重なります。
決め事3：仕掛在庫の「置き場」をどちらが持つか。 工程間バッファ、ライン上の仕掛、検査待ち置場を、ERPの保管場所マスタに登録するかどうか。登録すればERPでも見えますが、ERPの在庫トランザクションが激増します。登録しない場合は、ERPには「製造仕掛」という1つの箱だけを持たせ、その内訳はMESが持つという分担にします。後者を選ぶなら、月次で「MESの内訳合計＝ERPの製造仕掛残高」となることを検証する仕組みを作ります。
よくある実装の失敗
失敗1：仕掛のステータスを増やしすぎる。 「加工待ち」「加工中」「加工済」「検査待ち」…と工程ごとにステータスを作ると、状態遷移の組み合わせが爆発し、遷移漏れによる幽霊仕掛が発生します。ステータスは物の状態（良品／保留／不良／廃棄）だけにし、どこまで進んだかは「最終完了工程」の属性で表現するのが保守しやすい設計です。
失敗2：滞留した仕掛の時効管理をしない。 どの工場にも、指図が閉じられないまま数個だけ残る仕掛が発生します。これを放置すると、年に数百件の幽霊仕掛が積み上がり、棚卸のたびに調査対象になります。「最終更新から30日経過した仕掛を自動でリストアップし、処置を強制する」という運用機能を最初から入れてください。後付けすると、既に溜まった分の棚卸しから始めることになります。
失敗3：棚卸のときだけMESを止める。 実地棚卸のあいだMESを停止し、差異を手作業でERPへ直接投入する運用にすると、MES側の在庫が実態とずれたまま残ります。棚卸差異は必ずMESを経由して調整し、調整記録を残します。これは在庫管理機能の責任分界を決めるときにセットで合意すべき点です。
製品による実装差と、確認すべき質問
WIP管理は多くのMESが標準で持ちますが、次の3点で実装差が出ます。
- 仕掛の分割・併合ができるか：1つの仕掛ロットを2台の設備に分けて流す、複数の仕掛をまとめて次工程へ流す、という操作が標準機能であるか。ない製品では、ロット番号の付け替えを人手で管理することになり、系譜が切れます。
- 数量の差異理由を必須入力にできるか：前工程完了数と当工程投入数が合わないとき、理由の入力を強制できるか。ここが任意入力だと、差異の原因分析が事後にできません。
- ERPへの送信失敗時の再送設計：連携が失敗したトランザクションがキューに残るか、消えるか。消える製品では、ネットワーク断のたびに手動での突き合わせが発生します。デモの際にネットワークを物理的に切って、復旧後にどうなるかを見せてもらうのが最も確実な確認方法です。
工程間の仕掛をERPで見えるようにすべきですか？
原則として不要です。ERPが必要とするのは金額としての仕掛残高であり、どの工程に何個あるかという内訳ではありません。内訳が必要になるのは、①長納期品で顧客に進捗を回答する必要がある、②仕掛のまま拠点間を移動する、③会計上、工程別に仕掛を評価する方針がある、の3ケースです。この3つに当てはまらない場合、ERPには集約値だけを渡し、内訳はMESで持つほうが両システムとも軽くなります。判断は情シスではなく経理・原価管理部門と一緒に行ってください。
バックフラッシュをやめて実消費に変えたいのですが、途中から切り替えられますか？
品目単位で切り替えるなら可能です。ただし、切り替え日をまたぐ指図の扱いを決める必要があります。実務的には、切替日以降に発行される指図から新方式を適用し、既発行の指図は旧方式のまま完結させるのが最も事故が少ない進め方です。同一指図の途中で方式を変えると、消費が二重計上または未計上になります。また、実消費に変えると現場に材料スキャンの操作が増えるため、システムの切り替えより現場運用の準備期間のほうが長くかかります。1ラインで2〜3か月の並行運用を見込んでください。
MESの仕掛数量を、そのまま原価計算に使えますか？
数量としては使えますが、そのままでは金額になりません。金額化には単価（材料費・労務費・経費）が必要で、これはERP側のマスタです。実務では、MESが「指図別・工程別の消費数量と工数」を出し、ERPが単価を掛けて原価を計算する分担が標準です。ここで注意すべきは、MESの工数が「その工程に何分かかったか」なのか「作業者が何分従事したか」なのかという定義差です。1人が2台を掛け持ちする現場では、この2つは一致しません。原価計算に使うなら、後者（従事時間）を按分できる形で記録する必要があります。
