製造業の生産指図分割・統合管理システム導入｜数量と履歴をつなぐ設計

製造業で生産指図の分割・統合管理システムを導入するなら、画面に「分割」「統合」ボタンがあるかより、指図を組み替えた後に数量・仕掛・材料・品質・納期の関係を追えるかを確認したい。設備停止で残量を別ラインへ移す、材料が一部だけ入ったので先行着手する、同一条件の小口指図をまとめて段取りを減らす。こうした変更は珍しくないが、指図番号だけを付け替えると実績の帰属先が曖昧になる。本稿はタイの製造拠点を想定し、導入前に決める業務ルール、必要なデータ、RFPと受入試験の観点を整理する。

生産指図の分割・統合とは何を変える操作か

生産指図は製造する品目、数量、予定日、材料、工程を束ねる業務上の単位である。Microsoftの生産指図ライフサイクル説明でも、製造対象・数量・予定完了日と、材料および工程が指図に含まれる。したがって分割を「数量欄を二つにするだけ」と定義すると、材料引当、工程進捗、仕掛、品質履歴、原価の扱いが未決のまま残る。統合も二つの番号を一つに見せるだけでは済まない。顧客・品目・仕様・工程・納期が同じか、どの時点から一つの実行単位として扱うかを判定する必要がある。

ここでは用語を次のように分ける。分割は一つの親指図の未実行量を複数の子指図または実行単位へ割り当てる操作。統合は複数の需要または指図を共通の実行単位へ結び付ける操作。再配分は既に始まった作業の残量・設備・期限だけを変更する操作。実務では同じ「分割」と呼ばれていても、ERP上で新しい生産指図を作る場合、MES内でジョブを分ける場合、同じ指図の下で実行ランだけを分ける場合がある。どの階層を変えるのかを先に明確にする。

ISA-95を参照したOPC Foundationのジョブ管理モデルでは、Work Schedule、Work Request、Job Orderという階層を示し、数量を複数のWork Requestに分ける例がある。Job Orderは作業センターで実行する仕事を表し、Job Responseは実行した仕事の報告を表す。この考え方を使うと、ERPの受注・生産計画と、MESの現場ジョブを同じ番号に無理に押し込まず、親子関係と応答関係で追える。標準は特定製品での「統合ボタン」の存在や原価処理まで保証するものではない。導入側が自社の境界を設計する必要がある。

分割が必要になる場面を四つに分ける

第一は材料不足による部分着手。必要量のうち確認できた材料だけで先行できるなら、着手可能量と保留量を分けたい。このとき単純な比例配分ができない副資材、最小ロット、セット材料がないか確認する。材料が不足する場合の部分着手は導入時に検討すべき業務ケースである。SAP S/4HANA CloudのOrder Split文書は品質上の理由、能力制約、部分数量の必要日変更を例に示すが、許される状態や対象工程は製品仕様に依存するため、すべてのシステムに当てはめない。

第二は設備や工程の制約。機械停止、能力差、外注への振替が起きれば、未着手分と既に加工された仕掛を区別して残量を移す必要がある。加工済みの現品を新指図へ移す場合、現品ラベルと実績履歴をどう継承するかが重要だ。単に子指図を発行し、旧指図の実績を残したまま新指図に全量を再投入すると二重計上になる。

第三は納期・優先度の変更。顧客が一部数量を先納めしてほしい場合、元の需要との紐付けを保ったまま優先ラインへ回す。分割後の各数量に対して希望日、約束日、製造完了見込みを別々に持てるかを確認する。生産日程の再計算が必要なら、変更前の計画との差分と承認者を残す。

第四は品質上の隔離・手直し。同じ親指図の中でも特定ロットや工程通過分だけ検査待ち、隔離、再加工にすることがある。合格分と保留分を同じ「完成数量」に戻すと追跡性を損なう。分割後は良品・不良・手直し・保留の各数量を明示し、どの材料ロット・設備・作業条件から生じたかを辿れる状態にする。

統合が有効な場面と、してはいけない場面

統合を検討するのは、同じ品目・仕様・工程条件の小口需要を一つの段取りで流せるときである。ただし「一緒に作る」と「元の需要を消す」は違う。製造実行をまとめても、受注先、納期、出荷先、優先順位は元の需要行に残す設計が安全だ。完成後の数量をどの需要へ何個引き当てるかを保持してこそ、顧客別の納期回答ができる。

Microsoft Dynamics 365のConsolidated batch ordersは、バルク品と包装品の関連バッチオーダーを一つのビューで確認する製品機能であり、「複数の需要・実行単位を関係付ける」参考例となる。一方、それを全製造方式に共通する統合の意味だと解釈しない。離散製造で複数の作業指図をまとめる場合は、ERPの原価・在庫単位、MESの作業単位、現品の識別単位を別々に確認する。

統合を避けるべき条件は、製品リビジョンが違う、承認済み工程が違う、品質検査条件が違う、顧客による材料指定が違う、トレーサビリティ上の隔離が必要、あるいは原価の帰属先を分ける必要がある場合である。同一品番だけで自動統合する規則は危険だ。統合可能性は「品番一致」ではなく、実行条件と会計・顧客条件を含む判定表で決める。

ERP・MES・現場端末の責任境界を決める

システム導入の最初の難所は、どこが元指図を管理し、どこが現場の実行単位を管理するかである。ERPが受注、計画、材料所要、会計を持ち、MESが工程への指示、実績、設備、現品を持つ構成なら、親指図の計画変更と、現場ジョブの再配分を同じ更新として扱わない。ERPに戻す必要があるのは、需要や計画数量、材料引当、原価に影響する変更である。MES内に閉じられるのは、承認された親指図の範囲内での作業順や作業センターの変更など、会社が規則で定めた範囲に限る。

OPC Foundationが示すISA-95ジョブモデルは、上位の作業計画と現場のJob Order・Job Responseを別の情報として扱う。これは「どちらの画面で操作するか」だけで境界を決めない理由になる。変更指示、承認、実行、実績応答の各イベントに責任主体を割り当て、片方向更新だけで済ませず、拒否や再送も設計する。

現場の作業手順書の版管理は別の論点である。作業指示システムの導入と旧版失効では、改訂版が現場へ渡った後に旧版を止める要件を扱った。本稿では、分割・統合した各実行単位がどの有効な手順版を参照するかまでを接点として扱う。また、工程間の物理的な滞留を数える方法は仕掛品管理の実務を参照できる。指図の親子関係が正しくても、現品の置き場と数量が合わなければ、現場の仕掛は見えない。

データモデルは「親子」と「由来」を分けて持つ

最低限、親指図ID、子指図または実行ランID、元の需要行ID、品目・リビジョン、計画数量、単位、工程、作業センター、予定日、状態、変更理由、承認者、変更時刻を持つ。加えて、材料ロット、現品・容器ID、検査結果、良品・不良・保留・手直し数量、作業実績を実行単位に結び付ける。「親子」はどの指図から分けたか、「由来」はどの受注・材料・現品・品質判定から来たかを表すため、別の関係として保存する。

数量の基本式は、分割前の対象数量＝分割後の対象数量の合計、という保存則である。ただし実績が一部入っている指図では、計画総量ではなく未実行残量を分割対象にするのか、仕掛を移管するのかで式が変わる。導入時には数量種別ごとに保存則を定義する。例として、計画数量、投入済み数量、工程完了数量、良品数量、不良数量、保留数量、廃棄数量を一つの「数量」に混ぜない。単位が個・箱・重量の間で変わるなら換算係数と丸めルールを記録し、端数を勝手に消さない。

例示として、親指図1,000個のうち工程Aを600個が通過し、400個が未着手だとする。設備停止で未着手400個を別ラインへ移すなら、親に残す600個と子へ移す400個は計画上は合う。しかし工程A通過実績600個を子へ移してはいけない。もし通過済みのうち200個も別工程へ移すなら、200個の現品ID、工程A実績、使用材料ロット、品質状態を移管イベントで結ぶ。1000という数字は説明用の仮定であり、標準的なロット規模や効果を示すものではない。

分割・統合を何度も行う工場では、単純な「親ID一つ」だけでは足りない。AをBとCに分け、後でCの一部をDへ移し、BとDを同じ工程で流すこともある。履歴を上書きせず、変更イベントごとに「元ID、先ID、対象数量、工程位置、理由、承認、時刻」を残す。これにより、今日の実行形態と、過去にどの経路でそこへ来たかを両方再現できる。表示上の親子ツリーはこのイベントから作れても、監査に必要な原記録は消さない。

「統合」の後も受注と原価の帰属を残す

一つのラインでまとめて流した結果を、どの注文へ戻すかは統合前に決める。例えば同じ仕様の受注Aと受注Bを同一バッチで生産しても、出荷優先順位や売上先は別である。必要な設計は「実行バッチID→元需要行ID→配賦数量」の対応であり、完成数量を単一の受注へ自動で全量付ける処理ではない。先入先出、指定ロット、顧客専用材料などの規則があるなら、その規則を配賦時の制約として明示する。

原価についても同様である。段取り時間や共通材料をどの指図へ配賦するか、追加の手直し費用をどちらへ付けるかを事前に合意する。これはシステム機能の有無だけで決まらない。会計方針と現場の採番・実績単位が一致している必要がある。分割後の原価差異を親に集約するのか、子ごとに評価するのか、あるいはERP標準の制約に合わせるのかを製品デモで確認する。会計締め後に履歴を遡及変更する操作は、監査と在庫評価の観点から特に慎重に扱う。

ステータス別に許す操作を決める

「どの時点でも分割できる」と約束する製品説明には、例外を確認する。作成前、リリース済み、着手済み、部分完了、品質保留、完了報告済み、会計締め済みでは、変更できる対象が違う。SAPのOrder Splitには対象の状態や工程に条件がある。OracleのWork OrderをExecution Runsに分ける機能は、リリース前にラン数や数量を設定し、実行ラン単位で生産・材料・品質・系譜を追跡する一方、並列工程やシリアル追跡の指図などには制約を明示している。したがってデモでは、機能名より「自社で多い変更時点」を再現して確認する。

次の判定表を現場、計画、品質、原価の四者で埋めると、仕様漏れを減らせる。

製品ごとに許可範囲は違う。自社の運用として、禁止する操作は画面の非表示だけでなくAPIにも適用し、必要な場合は取消・再発行・訂正伝票という代替手順を定める。権限も「分割を提案できる人」「承認できる人」「現場で実行できる人」を分ける。夜勤で承認者が不在なら、緊急変更の委任・事後確認をどこまで認めるかも定めたい。

現場で使える分割・統合の承認フロー

画面遷移を設計する前に、ひとつの変更要求を紙に書いて追う。起票者は対象指図と理由を選び、変更前後の数量、対象工程、材料・現品、納期への影響を提示する。システムは保存則と統合条件をチェックし、変更差分を承認者へ示す。承認された時点で新しい実行単位を発行し、旧指示の一部を失効させる。現場端末は古いバーコードを読んだ場合に警告する。作業が進んだ後は実績を新しい単位に記録し、ERPへ応答する。拒否された場合は新指図を作らず、元の状態を維持する。

このフローに再送と競合を含める。通信が切れ、ERPで分割が確定したのにMESが受け取れなかった場合、同じイベントを再送しても子指図が二重作成されないよう、変更要求IDを一意キーとして扱う。MES側で作業開始済みの間にERPが別の分割を指示した場合は、後勝ちで上書きせず、競合として保留し担当者へ返す。時計の時刻差だけで順番を決めず、バージョン番号または承認済みイベント番号を用いる。これは特定標準に必須の実装というより、二重指図と履歴断絶を防ぐための導入設計上の推奨である。

実績をERPへ戻す際は、元指図・子指図・実行ラン・工程・良品/不良/保留数量・材料消費を一つの応答にどう表すか確認する。OPC FoundationのJob Responseモデルは、作業の結果と使用した材料・設備などを関連付ける枠組みを示す。実際のERP-MES接続ではコード体系や処理順の違いがあるため、失敗時の再実行と照合を設計する。インターフェースのエラー監視・再送の詳細はERP–MES連携のエラー監視と再処理で扱っている。

導入方式の比較：標準機能、MES拡張、個別開発

候補製品の比較表には、単なる機能有無ではなく「どの階層で、どの状態から、何を保つか」を書く。ERP標準の指図分割は計画・会計との整合が取りやすい一方、現場の容器単位や工程途中の動きに合わせるには設定・拡張が要る場合がある。MES内のジョブ分割は現場実行に近い一方、ERPへ反映すべき計画変更と切り分けなければならない。個別開発は現場の例外を表現しやすいが、バージョンアップ、監査、長期保守まで自社で背負う。どれが有利かは既存ERP、現場の例外頻度、原価粒度で変わる。

選定時は「分割できる」というデモだけで採点しない。例えば親1,000個のうち600個が工程Aを通過し、その600個を別設備向け200個、品質保留200個、元ライン継続200個に分け、未着手400個は親に残すケースを実演してもらう。続いて再送、取消、締め後の訂正まで試す。製品が一部の操作を標準で許さないなら、その制約を明示した業務代替手順まで提案に含める。制約が見つかったこと自体は失敗ではなく、稼働後に現場がExcelへ戻る原因を先に発見できたという成果である。

RFPに入れるべきデータとテスト条件

数量・仕掛・原価を三段階で突き合わせる

受入試験の数値は、画面に表示された総数だけを見て合否を決めない。第一段階では、変更直前の親指図を基準点として保存する。計画数量、工程別の投入・完了数、良品・不良・保留数、材料の予約・払出数、現品の容器一覧を同じ時刻のスナップショットとして採る。変更の途中で別の作業者が実績を登録すると比較が壊れるため、対象を一時停止するか、イベント番号で切り分ける。予定数量と実績数量を同じ列に足し込まないことも重要だ。

第二段階では、分割・統合イベントそのものを検査する。子指図を二つ作る場合、子の数量合計が分割対象の残量と一致するかを見る。既に作られた仕掛を移す場合は、数量だけでなく現品IDごとの移動前後の指図、工程、場所、品質状態を比較する。一つの現品IDが二つの指図へ同時に存在してはならない。品質保留の現品は、保留権限が解除されるまで出荷引当候補にもならない。画面表示が正しくても、ラベルや倉庫システムに古い指図IDが残るなら未合格とする。

第三段階では、下流の伝票と現物を突き合わせる。材料払出が親に残るのか子へ移管されるのか、ERPの在庫移動とMESの消費記録を照合する。工程実績の後に良品・不良の分類が変わった場合は、訂正イベントが原記録を参照できることを確認する。原価は見積原価と実際原価を混ぜず、費目別に親子へ割り当てた結果とERPの原価差異を確認する。締め済み期間の訂正は、元伝票を消してつじつまを合わせるのでなく、承認済みの調整伝票として説明できなければならない。

FAT/SATで通信断と同時操作を再現する

現場で起こりやすいのは、変更操作自体の失敗よりも、複数システムの確定時刻がずれることだ。FATではERPで変更要求を確定した後、MESへの送信を意図的に止め、同じ要求を二度送る。期待する結果は子指図一件であり、二度目は同じ要求への再応答として記録されることだ。次にMES側で作業を開始してからERPに古い版の変更要求を送る。期待する結果は自動上書きではなく競合としての拒否または保留であり、担当者が何を比較すべきか画面とログで分かることだ。

SATでは実機の端末をオフラインにし、古いラベルのスキャン、新しい子指図のスキャン、復旧後の再送を試す。オフライン中に作業継続を認めるなら、どの範囲を仮登録でき、どの時点で監督者確認が必要かを明確にする。複数端末から同じ現品を同時に移管しようとしたとき、片方だけが確定し、もう片方には理由付きのエラーが返ることも確認する。試験記録には入力、操作時刻、通信状態、期待結果、実際の結果、差異の修正責任者を残す。

これらのテストは製品固有の標準機能を断定するものではない。各社の導入構成が、想定する業務上の不変条件を満たすかを測るためのケースである。標準機能で難しい場合は運用による回避もあり得るが、そのときは「誰が、いつ、どの照合結果を見て、どの承認で進めるか」を手順書へ書き、見積範囲に教育と監査の工数を含める。曖昧な手作業を無償の補完策として扱うと、稼働後に数字が合わない理由を説明できなくなる。

RFPには現在の業務フロー、指図件数の傾向、変更理由の実例、製品・ロット・シリアルの追跡粒度、ERPとMESの機能境界を添える。件数や例外率は自社データで記入し、一般的な数値を借りない。サンプルデータには、未着手の分割、部分完了後の残量移動、手直し品の隔離、小口需要の統合、取消、重複メッセージ、通信断、月締め後の訂正を入れる。各ケースについて、入力データ、期待される指図系譜、材料・現品・実績の帰属、ERP返却内容を表にする。

受入試験では画面だけでなく、現場端末、バーコード、ラベル、インターフェース、会計・在庫伝票まで追う。紙の作業指示が残る工程では、旧指示の回収と新指示の交付を試験項目に入れる。タイの工場で複数言語の手順書を使うなら、指図を分けた後も各言語で参照する手順版が同じか確認する。操作権限の言語表示と、現場の用語が一致しているかも試す。

FATでは設定された業務ルールと例外処理、SATでは実際の設備・端末・ラベル・ネットワーク条件を確認する。試験の「成功」はボタンが押せたことではない。分割・統合後に、現物一つを選んで元需要、元指図、材料ロット、工程実績、品質判定、現在地、出荷割当まで辿れることを受入条件にする。追えない箇所があれば、データモデルとイベント設計へ戻る。

費用対効果は指図変更の手戻りから見積もる

費用を比較する前に、現状の指図変更を数週間分抽出し、変更一件ごとに人手で行った作業を測る。計画表の修正、ERP再入力、現場指示の再印刷、材料予約のやり直し、仕掛探し、品質履歴の突合、出荷回答の修正である。各作業の所要時間は現場で測り、担当者の負担と、誤指示・二重計上が生じた際の再処理費用を別々に集める。ベンダーの一般的な削減率を自社の効果として転記しない。

一方、導入費用にはライセンスだけでなく、ERP-MES連携、指図・現品マスターの整理、ラベル変更、端末設定、権限設計、教育、試験、運用保守を含める。段階導入なら、最初の工程で得られた実測値を次工程の判断に使う。統合で段取りが減っても、顧客別配賦や検査が増えれば純効果は小さくなる。分割で納期を守れても、材料移管や品質判定が遅れればメリットは消える。改善効果は「指図変更の処理時間」「現品探索時間」「未照合数量」「納期回答の更新時間」などの自社指標で追う。

導入を三段階で進める

指図分割・工程分割・実行ラン分割を混同しない

ベンダー資料で「split」と記載されていても、分ける対象は同じではない。SAP S/4HANA CloudのOrder Splitは親の生産指図から数量を取り出し、別の子生産指図を作る機能として説明される。これに対し、工程内のジョブ分割は同じ工程を複数の作業単位に分けることであり、工程ルートの変更は通過する工程や順序を変えることだ。いずれも必ずERP上の親子指図を増やすわけではない。OracleのExecution Runsは一つのWork Orderを複数の実行ランへ分ける例で、指図本体で管理する予約・原価などと、ラン別に記録する製造・検査などの粒度が異なる。MicrosoftのConsolidated batch ordersは、バルク品と包装品に関係するバッチオーダーを一緒に見て管理する例であり、任意の二つの生産指図を履歴ごと一つへ変換する汎用機能ではない。

この違いは見積比較のときに表面化する。「分割可能」に丸が付いていても、需要行から分けられるのか、指図の未実行残量を分けられるのか、工程内のジョブだけを分けられるのかで現場効果が変わる。同じく「統合可能」と書かれていても、計画一覧でまとめて見えるだけか、設備で一つの実行バッチにするのか、原価・在庫伝票まで単一化するのかは別である。RFPでは一語で質問せず、変更前後の識別子と、どの記録がどの識別子へ紐付くかを図で要求する。

デモでは、分割直後に親と子をそれぞれ開き、指示数量と残量が合うことを確認する。次に現場端末で子のバーコードを読み、材料引当と有効な手順版が表示されるか確かめる。工程実績を一件登録して、ERPへ戻った数量、仕掛現品のラベル、品質記録のIDを順に追う。統合のデモでも、元の二つの受注行に異なる出荷予定を残しつつ一つの設備で実行できるかを確認する。ここまで追えれば、製品の言う「分割・統合」が自社の課題に合うかを判断しやすい。

第一段階は現状の定義。直近の分割・統合事例を数件選び、なぜ変更したか、誰が承認したか、どのデータを修正したか、現場で何が困ったかを時系列で描く。特に「未実行残量」と「工程途中の仕掛」が同じ欄で管理されていないか確認する。数量、単位、現品ID、需要行IDの欠落を先に洗い出す。

第二段階は業務ルールと接続設計。状態別の許可表、統合条件、数量保存式、権限、取消方法を決める。ERP、MES、品質、倉庫のそれぞれで誰が正本となるかを定義し、イベントID、再送、拒否、照合の流れを試験データに落とす。指図の分割・統合を機に、新しい品目体系や全工程の自動化まで同時に始めると、失敗時の原因が見えにくい。最初は例外が多く、現品を追いやすい一工程または一製品群に絞る。

第三段階は現場検証と拡張。FATで親子関係、数量保存、権限、再送を確認し、SATでラベルや端末の使用感、通信断、夜勤の承認運用を検証する。稼働後は手作業補正件数、指図と現品の不一致件数、変更から現場反映までの時間を追う。基準値は導入前に測る。問題が出たら、現場へ追加入力を求める前に、採番・イベント・画面表示のどこで情報が抜けたかを調べる。

よくある質問：生産指図の分割・統合管理システム導入

生産指図の分割とジョブ分割は同じですか？

同じとは限らない。ERPで独立した生産指図を増やす方法、MESで工程ジョブを分ける方法、同一指図の下で実行ランを分ける方法がある。原価、材料、納期、実績をどの階層へ結び付けるかで選ぶ。製品ごとの制約も確認する。

着手後の生産指図を分割できますか？

製品と指図状態による。未実行残量だけを分けるのか、加工済み仕掛も移すのかで必要なデータが違う。候補システムに、自社で頻出する着手後ケースを実演してもらい、現品と実績が二重計上されないことを確認する。

複数の指図を統合すれば原価も一つになりますか？

自動的にそうなるとは限らない。実行単位をまとめても、元受注と原価の帰属は別管理できる。共通の段取り・材料・手直し費をどう配賦するかは会計方針とERP機能に合わせて決める。

システム導入費用は何で変わりますか？

既存ERP・MESの標準機能、工程途中の現品管理の粒度、品質・倉庫・会計との接続、例外処理、ラベル・端末変更で大きく変わる。見積依頼には実際の変更ケースと受入試験を添え、同じ条件で比較する。

生産指図の完了処理と何が違いますか？

分割・統合は、実行中に「誰がどの数量をどの単位で作るか」を組み替える管理である。完了処理は、作業・品質・在庫・原価の結果を照合して指図を閉じる段階である。締め前の照合や未完数量の扱いは生産指図の完了処理を参照してほしい。

まとめ

生産指図の分割・統合管理は、操作ボタンの有無よりも、変更の前後で数量を保存し、現品と実績の由来を残し、元需要への帰属を失わないことが中心になる。最初にERP指図、MESジョブ、実行ランのどこを変えるかを定め、状態別の許可、統合条件、材料・品質・原価の扱いを一枚の判定表にする。製品比較では、平常時のデモに加え、部分着手後、品質保留、再送、取消、月締め後という自社の例外を試す。その結果をRFPとFAT/SATの合格条件へ落とせば、導入後の現場運用を具体的に評価できる。

タイ工場で指図変更の実例はあるものの、ERPとMESのどちらを正本にするか決まっていない段階でも構わない。TOMAS TECHでは、現場の一件を材料・仕掛・品質・納期まで追い、導入条件と受入試験に整理する相談を受け付けている。検討中のケースがあればお問い合わせから共有してほしい。

参考情報

• OPC Foundation, OPC UA for ISA-95 Part 4: Job Control — Work Schedule／Work Request／Job OrderとJob Responseの定義。
• OPC Foundation, OPC UA for ISA-95 Part 4: Job Control, full specification — Job OrderとJob Responseの情報モデル。
• Microsoft Learn, Production order lifecycle overview — 生産指図に含まれる情報と状態。
• Microsoft Learn, Consolidated batch orders — 関連バッチオーダーをまとめて見る製品例。
• SAP Help Portal, Order Split — 生産指図分割の理由、対象状態、制約の製品例。
• Oracle Cloud SCM, Split a Work Order into Execution Runs — 実行ラン単位での実績・品質・系譜追跡と制約の製品例。