製造業で生産指図変更管理システムを導入する際、難所は「変更を入力できるか」ではありません。指図を現場へリリースした後に数量、納期、部材、工程が変わったとき、誰が影響を確認し、どの版を承認し、端末や印刷物から旧版を退け、進行中の実績とERPをどう整合させるかです。本記事は、この一連の制御を調達仕様と試験項目に変えるための実務ガイドです。製品や業種によって変更可能な状態は異なるため、操作方法を一律に決めず、自社の運用条件を先に定義します。
リリース後の生産指図変更が別の課題になる理由
計画段階の指図では、数量や工程を変更し、再計算してから現場に流す余地があります。一方、リリース済み指図は作業者に見え、作業票が出力され、材料の引当・ピッキングが進み、作業開始や完了の実績が記録され得ます。Microsoftの製品資料でも、Releasedを現場と倉庫で実行可能な状態として説明し、作業登録や倉庫作業との接点を示しています。Microsoft:Release production orders。したがって指図の変更は、単なるマスタ値の上書きではなく、既に伝達された指示、物理的に動いた材料、記録済みの実績との調整です。
今回の対象は生産指図をリリースした後の変更管理です。設計変更の起票・承認とBOMマスタへの反映は設計変更とPLM・ERP連携の記事で、部材の払出自体は部材払出管理の記事で扱っています。本記事では、それらの結果を受けた個々の指図について、変更申請から新版の現場適用までをつなぎます。対象が同じ部材でも、設計変更番号と生産指図変更番号は同一ではありません。前者は何を作るべきかの承認、後者は「既に動いているこの指図を、どの時点からどう作るか」の承認です。
最初に定義する境界:どの状態で何を変えられるか
RFPの冒頭には、指図の状態ごとに変更可能な属性と必要な統制を表で明示します。たとえば計画・予定・リリース・着手・一部完了・完了・締めの状態は、それぞれ影響の範囲が違います。「リリース後も変更可」という一文では、開始済み工程や払出済みロットまで自動的に書き換えてよいのか判断できません。Microsoftの直前変更機能の説明には、BOM品目の置換対象をEstimatedまたはScheduledの指図に限る条件が明記されています。一方、SAP Business ByDesignの資料は、リリース後や着手後に一定の数量・日付を変更できる例を示しています。これは製品間の差であり、どちらかを全MES・ERPに一般化してはいけません。Microsoft:React to last-minute changes、SAP:Production Orders Quick Guide。
| 指図状態 | 変更の基本方針 | 画面・連携で必要な制御 |
|---|---|---|
| 計画・予定 | 再計画を前提に変更 | 所要量・能力・納期を再計算し、元の計画版を保持 |
| リリース済み・未着手 | 影響確認後に新版を配布 | 旧作業票と端末表示の失効、ピッキング済み材料の照合 |
| 着手済み | 変更の効力発生点を区切る | 実績済み数量と未着手残量の分離、仕掛品判定、現場の停止・再開 |
| 一部完了 | 残量だけを対象にするか分割指図を作る | 完了品・未完品・不適合品の追跡、重複実績の防止 |
| 完了・締め | 原則として履歴訂正の別手続き | 既存実績を無断上書きしない、修正理由と会計影響を残す |
表はシステムの標準仕様を断言するものではなく、発注者が決める統制案です。例外運用を許すなら、誰が、何を根拠に、どの範囲まで解除できるかを別途定めます。完了後の実績訂正・承認は生産実績訂正と承認の記事に切り分けます。指図版の変更と過去実績の訂正を同じボタンにまとめないことが監査上も重要です。

変更要求を「依頼文」ではなく評価可能なデータにする
申請画面には、指図番号と現行版、対象品目・ロット・ライン・工程、変更分類、変更前後の値、希望効力時点、理由、顧客要求または設計変更への参照を入力させます。自由記述は残してよいものの、数量変更、納期変更、部材・BOM変更、工程順序・設備変更を構造化しておくと、影響照会と承認経路の条件分岐に使えます。要求には一意の変更IDを付け、指図IDと版番号の両方に紐付けます。メールで承認した結果を後から転記するだけでは、承認時に見た変更前後の値を保証しにくくなります。
数量なら「総指図数量」「既完了良品」「不良」「仕掛」「未着手残量」を区別します。たとえば指図100個のうち40個が完了、10個が工程内にあり、指図総量を80個へ減らす場合、単純に未完了60個を40個へ置き換えるだけでは仕掛10個の扱いが残ります。この100・40・10・80という値は手順説明のための仮定であり、標準の配分ルールではありません。減産をどのロットと工程に適用するか、仕掛品を完了・保留・廃棄のどれにするかを承認前に決めます。
納期なら顧客納期、指図予定完了日、工程別開始・終了、部材入荷予定を別フィールドに置きます。ある日付だけを書き換えても負荷と材料は自動で整合しません。Microsoftの計画資料は、計画指図の変更が次の計画実行まで他の計画に反映されない場合や、BOM構成品の遅れが親品目の納期へ波及することを説明しています。これを導入時の確認項目として、再計画実行のタイミングと結果の見せ方を指定します。Microsoft:Production planning。
部材変更では、設計BOMの版を変えるのか、その指図だけ代替材を使うのかを分けます。前者はPLM・ERP側の承認が先、後者でも品質承認とロット追跡が必要な場合があります。工程変更では、作業順、設備、治工具、検査点、標準時間、作業手順書のどれが変わるかを記録します。変更要求に添付されたPDFだけを新版として現場に配ると、端末の工程順や実績入力項目と矛盾する危険があります。
影響照会は「どの部署が困るか」を具体的に返す
影響照会画面は、可否の単純な信号では足りません。計画、購買、倉庫、製造、品質、物流、原価の担当者が、同じ変更IDを見て別々の影響を確認できる必要があります。ISA-95は、ERPに相当する事業計画・物流の層と製造オペレーション管理の層の情報交換を整理する枠組みを示しています。そこから本記事では、ERPとMESの境界で「どの情報をどちらが正とするか」をRFPに記す設計を提案します。ISA-95自体が特定の承認ワークフローを義務付けるという意味ではありません。ISA:ISA-95 Standard。
| 変更の種類 | 申請前に照会したい対象 | 承認後に確認したい結果 |
|---|---|---|
| 数量増減 | 仕掛・完了数、材料引当、購買残、能力負荷、梱包単位 | 残量とピッキング指示が一致し、二重払出がない |
| 納期前倒し・延期 | 設備空き、材料到着、顧客出荷枠、外注先 | 再スケジュールと顧客回答の版が一致 |
| BOM・代替材 | 設計承認、対象ロット、払出済み部材、品質検査 | 新旧部材の消費がロット単位で追える |
| 工程・設備 | 着手済み工程、作業票、治工具、検査計画、作業資格 | 新工程だけが現場に表示され、旧工程を登録できない |
照会時点のスナップショットを残し、承認までに在庫・仕掛・設備状態が変わった場合は再評価を要求するのが堅実です。「申請時は材料があった」ことと「承認時も使える」ことは別です。しきい値を置くなら、たとえば数量差、残量比率、リードタイム差を自社のルールとして設定し、閾値超えだけ承認者を追加します。百分率や時間値は品種と生産形態で異なるため、本記事は一律の推奨値を置きません。
承認マトリクスと効力発生点をセットで定める
変更理由だけで承認者を選ぶと、同じ「数量変更」でも未着手と仕掛中の影響差を見落とします。承認ルートは変更属性、状態、金額・数量影響、顧客承認要否、品質リスク、ロット追跡要否で決めます。最低限、生産計画が納期・能力、倉庫が材料、製造が現場適用、品質が仕様・検査、必要時に営業または顧客窓口が約束納期を確認する構成が考えられます。これは運用設計の例であり、すべての会社に同じ決裁権限を求めるものではありません。
承認画面には「変更前→変更後」だけでなく、対象ロット・対象数量・発効条件を固定表示します。効力は単なるタイムスタンプより、未着手工程から、次のシリアル番号から、指定ロットから、現行仕掛の隔離確認後など、現物と突合できる単位で定義します。製造現場で回線が切れた場合や紙票が残る場合も想定し、承認時刻と現場確認時刻を別に記録します。承認済みでも端末への同期が未完了なら「適用中」とし、旧版と新版が併存する危険を見える化します。
旧版は削除ではなく失効させます。版番号、承認者、承認時刻、理由、効力発生点、旧版の最終有効時刻を保持します。Oracleの製造資料には、監査証跡を有効にすると旧値・新値、更新日時、実施ユーザーを記録できるとあります。採用製品で同等の履歴がどの属性まで残るかは、設定と実機で検証します。Oracle:Using Manufacturing。

現場反映:旧版を「閲覧できない」だけでは足りない
新しい版を端末に表示しただけでは、印刷済み作業票、端末のキャッシュ、設備に送った条件、倉庫のピッキング指示は残り得ます。RFPでは配信先ごとに、旧版の停止、新版の受信確認、未反映端末の検知、作業再開条件を記します。SAP MEの公開資料には、ERPからリリース済み指図の更新を受けた際にショップオーダーと対象SFCをholdし、オペレーターに通知して変更後に解除する例があります。これは特定製品の挙動ですが、変更中の現場作業をどう止めるかを試験する参考になります。SAP:Update of Released Production Order。
端末には「版が変わった」通知と、変更点の差分を出します。作業者が対象指図・ロット・工程を確認して受領した記録を残し、作業中の画面を開いたままでも旧版で実績登録できないようにします。紙運用を残す場合は、旧票回収の責任者、回収不能時の隔離策、再印刷票の識別を手順化します。QRコードを使う場合も、コード自体が旧版の内容を固定表示する設計なら失効チェックを迂回してしまうため、サーバー側で現行版を照合します。
工程変更は設備レシピや検査計画と連動することがあります。しかし設備側の設定を遠隔で上書きしてよいかは、設備と安全設計の評価が要ります。システム導入の範囲は「変更版の承認・配信・確認」までにし、設備パラメータの自動変更は別の安全審査を通す、という分離も選択肢です。物理工程が進んでいるときは、データ反映より先に仕掛品の所在を確かめる運用が必要です。
ERP・MES・実績の整合は差分と再送を設計する
ERPが指図ヘッダーと計画数量の正本、MESが作業順と実績の正本、といった分担を決めます。実際の分担は既存システムで異なるため、RFPでは項目単位の責任表を作ります。指図番号だけでなく版番号と変更IDを連携メッセージに含め、受信側が「既に適用した版」「古い版」「欠けた中間版」を区別できるようにします。受信側が同じ変更IDを再受信しても重複適用しないこと、失敗したら原因と再送状態を見せることが必要です。ISA-95 Part 5は、事業システムと製造管理システム間の取引モデルを扱います。ここで述べる冪等キーや再送設計は、その境界を実装するための提案要件です。ISA:Part 5。
実績は変更前に確定した分と変更後の分を別版に紐付けます。旧版の実績を「新しいBOMで作った」と見せかけてはいけません。数量変更後は、指図総量・完了良品・不良・仕掛・未着手残量が矛盾しないかを照合します。材料については引当、払出、返却、消費の各イベントを残し、差異を自動で帳消しにするのではなく、担当者へ例外として示します。完成品入庫との接続は完成品入庫管理の記事も参照してください。
連携エラー時は、現場に適用済みなのにERPが旧版のままという状態も、その逆もあり得ます。画面には「承認済み」「MES配信済み」「端末受領済み」「ERP更新済み」「整合確認済み」を別の状態で表示し、最終状態だけに丸めないようにします。照合ジョブは差異一覧を出し、再送の可否を判定し、手動修正時の理由を残します。どの時点で作業を止めるかは、部材・工程・品質リスクで決めます。
導入前に集める変更事例とデータ項目
要件定義を始める前に、直近の変更事例を数件選び、依頼から現場適用までの時系列を再現します。依頼者が見ていた指図版、口頭連絡を受けた班、実際に使った材料ロット、印刷票の回収時刻、ERPを変更した担当者、実績の締め時刻を並べると、単に「承認が遅い」のか「承認後の配信が遅い」のかが分かります。事例は成功例だけでなく、材料を払い出した後の変更、夜勤中の変更、指図を一部完了した後の変更、通信断を伴った例を含めます。件数を増やすことより、実物の票とシステム記録を突き合わせることが重要です。
同じ「数量」という名前でも、受注数量、指図数量、工程投入数量、良品数量、入庫数量は意味と更新者が違います。項目辞書には、名称、単位、正本システム、入力者、更新できる指図状態、参照先、履歴保存、外部送信先を記します。BOMも設計BOM、製造BOM、指図に展開した部材明細を区別します。版の付け方が各システムで異なるなら、指図版とBOM版を一つの文字列に押し込まず、対応関係を表にします。これをしないまま画面だけ先に作ると、承認対象は指図版Aなのに現場端末ではBOM版Bだけが更新された、といった曖昧な状態が残ります。
変更イベントの最低限のキーは、指図ID、指図版、変更ID、対象工程またはロット、発効条件、イベント時刻、発信システムです。端末の再送やERPからの再配信で同じイベントが届く想定にし、受信側は重複か新規かを区別します。時刻は現場表示のタイムゾーンとシステム間の保存時刻を分けて扱います。たとえばタイ工場と海外本社のERPが連携するとき、表示上の時刻だけを比較すると承認と適用の前後を誤読し得ます。順序判定は時刻だけに依存せず、版とイベントIDを組み合わせます。
既存データの欠損も先に調べます。過去の作業票に版がない、ロットが手書き、実績を日末にまとめて入力する、といった現状があれば、新システムが過去履歴を自動的に完全復元するとは期待できません。導入前の記録と導入後の記録の境界を定め、移行時点で残る仕掛品にどの版を割り当てるかを現場・品質・経理で確認します。必要な証跡の水準は製品の品質要求と契約条件に合わせて決めます。
この現状調査の成果物は、フロー図だけでなく「変更事例台帳」「項目辞書」「システム間責任表」「例外一覧」の四つにするとベンダー比較へ使いやすくなります。変更事例台帳をFATのシナリオに、項目辞書をAPIの確認に、責任表を障害時の切り分けに、例外一覧をSATの現地試験に転用できます。社内で答えられない項目を空白のまま見積依頼に出す場合は、前提未決として明記し、ベンダーに都合のよい仮定で価格を出させないようにします。
緊急変更と取り消しも通常フローの延長で管理する
設備故障や不良流出のおそれがあるとき、通常の承認を待てない場合があります。その場合でも「誰でも直ちに上書きできる」を緊急手順にしないことが重要です。緊急停止の権限、暫定措置を記録する人、後追い承認の期限、顧客連絡の要否、再開を認める責任者をあらかじめ決めます。停止・隔離は迅速に行い、恒久的な指図変更は影響を確認したうえで新版として承認する、という二段階の運用が考えられます。ここでの「後追い承認」は履歴を後から整えるためであり、承認を受けていない変更を通常の承認済みと表示する理由にはなりません。
承認後に変更を取り消す場合も、単純に旧版へ戻す操作は危険です。新版で既に製造したロットや払い出した部材があれば、旧版を再表示しても現物は戻りません。取り消し要求を新しい変更IDとして記録し、現時点のWIP、完成品、材料、検査結果を照会してから、さらに新しい有効版を発行します。試験では「承認直後で未配信」「一部端末だけ配信」「一部ロットは新版で製造済み」の各段階で、何を止め、何を保持し、何を再承認するかを確認します。変更を取り消した事実だけでなく、どのロットからどの指示が効いたかを追えることが、後の品質調査に役立ちます。
RFPに落とす要件:機能名ではなく判定可能な文にする
「変更管理機能があること」では、ベンダーはボタンの存在だけで回答できます。RFPには業務条件、期待する結果、証跡、失敗時の動きまで書きます。次の表は転記しやすい要求例であり、契約前に自社の品種、設備、権限表に合わせて調整してください。
| ID | 要求例 | 提示を求める証拠 |
|---|---|---|
| CM-01 | リリース済み指図の数量・納期・部材・工程変更を、変更前後値と理由を持つ申請として保存する | 画面とデータ項目一覧 |
| CM-02 | 着手済み指図では、実績済み数量と未着手残量を分け、変更の効力対象を指定する | デモシナリオと状態遷移図 |
| CM-03 | 材料引当・払出、工程負荷、品質検査、顧客納期への影響を承認前に表示する | 影響照会の入力・出力例 |
| CM-04 | 承認時の変更差分、承認者、日時、根拠、効力発生点を改変不能な履歴として追える | 監査ログの抽出例と権限制御 |
| CM-05 | 承認後に旧版を失効し、オフライン端末・紙票を含む未反映先を検知する | 配信失敗と復旧のデモ |
| CM-06 | ERPとMESの各更新を版・変更IDで突合し、重複受信と順序逆転を処理する | API仕様、再送仕様、例外画面 |
| CM-07 | 変更前後の実績・材料・完成品を版ごとに追跡できる | ロット/シリアルからの追跡デモ |
| CM-08 | 権限外変更、承認取り消し、競合申請、通信断を安全に拒否または保留する | FATの異常系結果 |
ベンダーへの質問は「標準機能」「設定」「追加開発」「外部製品」「対応不可」の区分で回答させます。画面でできる変更とAPI経由でできる変更が違う場合があります。ライセンス、監査ログの保存期間、モバイル端末のオフライン挙動、既存ERPの改修範囲も見積の前提として明記します。見積比較では価格だけでなく、CM-01からCM-08の実現方法と、変更時に止めるラインの範囲を比較します。
FATで確認するシナリオ:正常系だけでは足りない
FAT(工場出荷前の受入試験)では、実機または評価環境で指図の状態と変更種別を組み合わせます。テストデータは仮の品目とロットで構いませんが、端末・倉庫・ERPを含む連携経路は本番に近づけます。各試験では操作画面の成否だけでなく、イベント履歴、残量、連携メッセージ、旧版からの登録拒否を証拠として残します。
- 未着手の数量増:材料所要と能力を再評価し、承認前に現場表示が変わらず、承認後に新版へ切り替わること。
- 着手中の数量減:既完了・仕掛・未着手を区切り、減産対象のロットと残量が曖昧にならないこと。
- 納期前倒し:設備と材料の不足を警告し、承認者が代替案と顧客回答を確認できること。
- 部材代替:払出済み旧部材と未払出の新部材を混同せず、実際に消費したロットを追えること。
- 工程変更:着手済み工程を遡って新版へ変えず、未着手工程だけに新版が効くこと。
- 同時申請:同一指図・同一版への競合変更を検知し、後着申請を再評価へ戻すこと。
- 通信断・再送:端末またはERPが一時停止しても旧版を誤って受理せず、復旧後に一度だけ適用すること。
- 権限・取消:権限外ユーザーが承認できず、承認後の取消は別の履歴として残ること。
数値の合格基準は、実際の指図量やネットワーク条件で決めます。たとえば「何秒以内に全端末へ配信」という値を根拠なく固定するより、対象端末数、ネットワーク断の許容時間、停止が必要な工程を示し、試験で計測するほうが有効です。ISO 9001の監査実務資料は、生産・サービス提供の変更をレビューして管理する必要性に言及しています。ただし、特定のIT画面や応答時間を規定しているわけではありません。ISO/TC 176監査実務資料。

SATでは工場固有の「紙・端末・仕掛」を見る
SAT(設置後の現地受入試験)は、FATで使ったシナリオを工場の実設備、実端末、実作業者の権限、実際の通信経路で再実行します。特に紙の作業票が残る現場では、旧票の回収・失効の証拠を観察します。端末に新人と管理者が異なる権限で入った場合、夜勤引き継ぎ時、回線断から戻った場合も試します。多言語現場なら、変更理由・承認状態・効力点を作業者が同じ意味で読めるか、翻訳済み画面の運用テストを行います。
SATの合格条件には、変更後に実績・払出・返却・入庫がどの版へ紐付いたかを追跡できることを含めます。異常系でシステムが停止したなら、現場が安全に待機し、誰が解除したかが分かる必要があります。合格前に残った例外を「運用でカバー」と一括処理せず、暫定手順、責任者、解消期限、再試験の条件を記録します。
導入順序と費用を左右する論点
初期導入では、すべての変更を一度に自動化するより、発生頻度と影響が大きい指図・ラインから始めます。まず現状の変更票とシステムログを集め、変更種別、指図状態、影響先、滞留時間、手戻りの発生箇所を分類します。次に「正本」「版」「承認」「現場反映」「整合」の五つを最低限のデータモデルにし、1つの品種・1つのラインで試します。その結果をもとに工程変更や代替材、外注工程へ広げます。これは一般的な段階導入案であり、品質リスクが高い品種では先に統制範囲を広げる判断もあり得ます。
費用を見積もるときは、申請・承認画面よりも、既存ERPとMESのデータ項目差、旧作業票の運用、オフライン端末、ロット追跡、監査ログ、設備・検査システム連携を確認します。APIがあっても版や変更IDを運べなければ追加開発が必要です。既存ERPでリリース後の属性変更が制限される場合、無理に上書きするより、指図分割や残量用の別指図を作る設計が適することもあります。導入判断では、対象となる変更件数とリスク、改修対象、停止許容、受入試験の範囲をセットで比較します。根拠のない一律費用や削減率は提示しません。
よくある質問
生産指図変更管理システムはMESだけで導入できますか?
MESだけで画面を作れても、数量、納期、材料所要、在庫、会計に関わる値の正本がERPなら連携設計が要ります。最初に項目別の正本と更新権限を決め、承認結果、実績、差異をどちらへ送るかを明示します。ISA-95の層分けはこの対話の共通語彙になりますが、具体的な連携方式は既存製品と構成で決まります。
リリース後のBOM変更は、設計BOMを更新すれば自動で反映されますか?
自動反映を前提にしないでください。指図作成時にBOMが複写される製品があり、変更可能な状態にも条件があります。Microsoftの資料では生産BOMと工程が指図へ複写され、開始前に編集できると説明されています。Microsoft:Production order lifecycle。対象指図のBOM版、払出済み部材、着手状態を確認して、変更対象を明示する必要があります。
生産指図の数量・納期変更の承認者は誰ですか?
固定の役職名より、変更が触れる責任範囲で決めます。数量と納期だけでも材料、設備、顧客回答、品質判定に及ぶ場合があります。RFPでは変更状態と影響条件から承認ルートを判定し、代理承認と緊急時の記録も指定します。顧客が承認すべき変更は社内承認だけで完了扱いにしません。
FATとSATでは同じ試験を繰り返す必要がありますか?
核になるシナリオは共通にし、FATでは機能・連携・異常系を、SATでは実ラインの端末、紙票、権限、通信、仕掛品を確認します。同じ画面操作が成功しても、現場の旧票やキャッシュが残る問題はSATでしか見つからない場合があります。証拠の採り方と不合格時の再試験条件も事前に合意します。
まとめ
生産指図の変更管理を導入するなら、リリース後の変更を「申請→影響照会→承認→現場反映→旧版失効→実績・ERP整合」という一続きの業務として定義します。状態ごとの変更可否、効力発生点、現場の受領確認、版付き実績、連携失敗時の停止・再送をRFPに記し、FATとSATで正常系・異常系の証拠を取ることが肝心です。特定製品の標準機能を過信せず、自社の指図、材料、工程、品質ルールで実演を求めれば、導入後の手戻りを減らせます。
生産指図の変更票やERP・MESの現行フローがまだ整理途中でも、対象ラインと最近の変更事例からRFPの論点を一緒に洗い出せます。TOMAS TECHへ相談する。