製造業の緊急割込・生産順序変更システム導入｜現場を止めない承認設計

製造指図を現場へ発行した後、重要顧客から「今日中に先に作れないか」と依頼される。製造業で緊急割込の生産順序変更を管理するシステムを導入するなら、画面上で指図をドラッグできるかだけを比べても判断できません。先行する指図、既に払い出した材料、動いている設備、仕掛品、他顧客への約束を同時に確認し、誰が割込を認めたかを残す必要があります。本記事はタイの工場でERP、APS、生産管理システム、MESを組み合わせる担当者向けに、発行後の順序変更に絞った要件と受入試験を整理します。

生産順序変更で変えるもの、変えないもの

ここでいう「優先順位変更」は、発行済みの複数の製造指図について、ある設備・工程の次に処理する順番を入れ替えることです。受注数量、BOM、工程経路や指図の版そのものを変える話ではありません。そうした変更の承認と履歴は発行済み製造指図の変更管理で扱っています。指図の分割や統合が必要になれば製造指図の分割・統合管理の業務です。本記事の対象は、同じ指図群を保ったまま「どれを次に流すか」を変える意思決定です。

例として、同じ組立ラインにA、B、Cの指図がこの順で並び、Bには午後の顧客引取が約束されているとします。営業が新たな緊急指図XをAの後へ入れたいと要求しました。Xだけを前へ動かすと、Bの完了が遅れ、C向けの共通部品をXが先に消費するかもしれません。ラインの段取り替えも増える可能性があります。画面に「Xを最優先」と表示するだけでは、受入可能な変更だとは言えません。新旧の順序、BとCの完了見込み、材料引当、仕掛状態、代替設備、顧客への説明と承認までを一件の判断として扱います。

Microsoftは、製造指図のReleased状態を現場で実行可能になり、材料ピッキングも起こり得る段階と説明しています。したがって発行後の順序変更には、計画表だけでなく現場の実行状態を戻して考える設計が欠かせません。Oracleはディスパッチリストを設備別の工程開始時刻と順序を確認・調整する画面として説明し、工程を前後に動かした後にスケジュール修復を行う例を示しています。これらは製品機能の例であり、導入先の製品が同じ動きをするという意味ではありません。

最初に決めるのは「緊急」の定義と権限

「顧客が急いでいる」「営業部長から電話が来た」だけでは、現場ごとの解釈が揺れます。案件を分類し、要求者が証拠を添える入口を設けます。分類例は、顧客ライン停止回避、品質是正・代替品、通常の納期前倒し、社内在庫補充です。これらに自動で順位を与えるのではなく、顧客契約、損失、確約済み納期、実現可能性を比較する材料にします。予定外の割込を「緊急」と呼べば常に通る運用は避けます。

依頼を登録できる人と、実行を許可できる人は分けます。営業は顧客要請と希望時刻を記録し、生産計画担当は候補をシミュレーションし、資材担当は部材、製造監督者は現場安全と段取り、営業責任者は遅れる顧客への説明を確認します。最終承認者は工場が決めます。現場監督者に限定した緊急権限を設ける場合でも、どの条件で暫定実行できるか、何分以内に追認するか、追認されなければどこまで戻せるかを事前に決めます。権限表は役職名だけでなく、金額、遅延幅、品質・安全影響、顧客区分などで分岐させられます。ただし運用開始時から複雑にしすぎず、例外がどこへ集まるかを見て改訂します。

変更禁止の時間帯を工程ごとに定義する

「凍結期間」や「frozen horizon」は、単に今日の予定を固定する数字ではありません。開始済み工程、治具を組んだ工程、材料をラインへ払い出した工程、顧客引取に合わせて輸送を手配した工程では、変更できる範囲が異なります。Oracle Production Schedulingのfixed time fenceは、設定によってその期間に開始する発行済み指図をfirm扱いにする機能例です。ただしそれを設定するだけで、各現場工程の変更可否や例外承認が一律に決まるわけではありません。計画上のフェンスと現場の変更禁止条件を別に定義します。

実務では、工程状態を少なくとも「未準備」「材料引当済み」「ピッキング済み」「段取中」「加工中」「品質判定中」「完了」に分けます。未準備なら計画担当の権限内で候補を作れるでしょう。ピッキング済みなら返却・再引当の責任者を指定します。段取中は残作業と復旧時間を確認します。加工中の指図を画面から消しても設備は止まらないため、現場確認なしの自動上書きを禁止します。品質判定中のロットを次工程へ流す順番も品質許可と連動させます。どの状態で誰が変更できるかを状態遷移表にし、承認画面とMES端末の両方で同じ制約を適用します。

凍結範囲はライン全体か個別設備か、時間かイベントかも決めます。例えば「次の2時間」では、設備停止で作業が進まないと凍結窓だけが時間経過で消えます。一方「現在着手中と次の1件」なら、現場の確定作業を守りやすいことがあります。どちらを採るかは製品特性、段取、材料移動、作業者配置によります。まず実際の割込案件を再生し、停止させてはいけない作業が画面から動かせないことを確認してください。凍結解除には例外の理由、承認者、適用時刻を必要とします。

緊急オーダー割込の影響を四つの制約で見る

第一に材料です。緊急指図Xの部品が倉庫にあるだけでは足りません。引当済み、品質保留、代替不可、ロット先入先出、補充予定、現場払い出し済みを区別します。Xに材料を移せばBの開始が止まる場合は、Xの実現可能性とBの遅延を同じ画面に出します。部品を借りる運用でも、元の引当先、返却・再調達期限、顧客承認が必要な代替かを残します。

第二に能力です。設備の空きだけでなく、段取品種、金型・治具、検査機、保全停止、作業者資格、シフト終端を確認します。Microsoftの有限能力スケジューリングは既存予約を考慮し、能力が足りなければ後ろへ移す例を示します。有限材料を合わせると、材料と能力が同時にそろう時刻が必要です。緊急案件だけ「空いているように見える」場合は、手作業で確保した予約や外注工程がデータから漏れていないかを調べます。能力の計算方法を分かりやすくするには能力カレンダーと生産スケジューリングも参照してください。

第三に仕掛品です。Bの前工程がすでに完了し、専用容器でライン横へ移動していたら、Xの割込で滞留場所が必要になります。滞留時間の上限がある工程や、工程間の先入先出が品質条件なら、単なる納期計算では判断できません。Xを入れた結果、Bの仕掛が上限を超える、Cの前工程が作れず飢餓状態になる、後工程の検査待ちがあふれる場合もあります。計画画面に工程間WIPと保管能力の警告を出し、代替置場と品質条件を明示します。

第四に顧客約束です。Bの内部予定日が一時間遅れるだけでも、輸送便が一日一便なら顧客着日は翌日になります。逆にライン完了が遅れても出荷余裕で吸収できる案件もあります。「工程終了見込み」「工場出荷見込み」「顧客に約束した日時」は別フィールドに保持し、計画再計算で顧客約束を自動上書きしない設計が必要です。割込の利益を示すときは、押し出される指図と顧客の一覧を添え、どの顧客への通知が必要かまで決めます。納期の四つの日付管理は納期管理システムのRFPガイドも参照できます。

「新しい順位」だけでなく押し出される指図を表示する

承認画面には緊急指図だけを大きく表示しがちです。しかし判断の中心は、何を犠牲にするかです。新旧順序を横に並べ、動いた指図を色で示し、各指図の着手・完了・出荷・顧客着見込みの差を同じ単位で見せます。材料不足、段取回数、残業・外注の必要性、品質保留、仕掛置場の超過も警告として分けます。影響なしと出た場合でも、計算対象の設備・期間、使用したデータ時刻、未取得イベントを表示しなければ信用できません。

優先順位が同じ指図のタイブレークも明文化します。例として、確約納期、材料準備完了、段取類似性、要求登録時刻、顧客契約上の義務という順の比較があります。しかし単純な重み付きスコアは「高得点だからBを遅らせてもよい」という許可にはなりません。安全・品質条件と契約上の約束はハード制約、段取効率は最適化条件として分けます。ルールを更新したら、旧ルールで承認した案件の解釈を変えないよう、ルール版と入力スナップショットを残します。

APS・ERP・MESの境界を「順序の正本」で決める

ERPは受注、製造指図、引当、在庫、原価、顧客約束の正本を持つことが多く、APSは能力・材料制約を使って候補順序を計算し、MESは現場の次作業と実績を扱います。ただし製品名から正本を推定せず、導入先でイベント別に決めます。「計画順序はAPS」「現場に配信した順序はMES」「承認済みの変更要求と顧客影響は共有ワークフロー」のように、状態ごとに正本が変わる設計もあります。その場合、どの版が現場で有効かを一意に示す必要があります。

候補シナリオをAPSで作る段階では、現場端末へ配信しません。承認が終わり、現場の最新状態でも制約が満たされることを確認してから、有効時刻と版番号を付けてMESへ送ります。MESは受信を確認し、未着手の対象工程だけを更新します。受信時に工程が開始済み、設備停止、材料払出済みへ変わっていたら、黙って上書きせず競合として返します。APIタイムアウトで再送するときは変更要求IDと版番号で重複適用を防ぎます。配信成功と端末反映は別の事象として記録し、端末がオフラインなら監督者に代替手順を提示します。

現場の紙指示書も問題になります。朝に印刷したリストが残ったまま端末に新順序だけ表示されると、班長と作業者が違う順序を信じます。紙を使う場合は失効時刻または版番号を明示し、旧版の回収・廃棄責任者を決めます。多言語現場では「割込申請」「承認」「適用済み」「現場確認」の訳語を統一し、色だけに依存しない表示にします。時刻は工場現地時間とタイムゾーンを明記し、ERP側のUTC時刻との変換試験も必要です。

システム導入RFPに書くべき機能と非機能

RFPでは「ドラッグ&ドロップ対応」と書くより、再現可能な業務シナリオで要求します。例は「A→B→Cが発行済みで、Bを翌日出荷する状態でXをAの直後へ申請する。Xの部品は在庫にあるがBへ引当済み。Xを実行するとBの顧客着が一日遅れる。システムはその差と制約を表示し、承認前は現場順序を変えず、却下すれば元の順序を保持する」です。各ベンダーには自社のサンプルデータだけでなく、匿名化した実際の設備、シフト、部品、指図、仕掛、顧客条件で説明させます。

機能要件は、①申請と理由コード、②候補順序の複数案、③凍結条件、④材料・能力・WIP・約束への影響、⑤権限と承認、⑥配信・端末確認、⑦取消と再試算、⑧監査・通知、の一連の流れで記述します。目的関数やルールの設定項目を列挙するだけでは不十分です。どの計算を何秒以内に返すか、データは何分以内の実績を使うか、状態が変わったとき再計算するか、候補がないとき理由をどう示すかを指定します。応答秒数とデータ許容遅延は工場で実測して決め、根拠のない「リアルタイム」を要求しません。

非機能要件には、工場ネットワーク障害時の手順、再送の冪等性、変更の同時実行、ロール変更の反映、操作ログの保持期間、監視、バックアップ、復旧時の整合、端末の多言語表示を入れます。同時申請があるなら、片方のシミュレーション開始後にもう片方が承認された場合、古い候補をそのまま適用できないようにします。Microsoftのスケジューリング説明にも並列処理で同じ資源の予約が競合し得る例があります。これは特定製品の内部実装例ですが、どの製品でもRFPでは「承認直前に最新状態を再検証する」試験が有効です。

データ品質を測らずに「最適な順序」は出せない

計画計算は入力の整合を保証しません。ERP上の部品在庫が十個でも、現物の三個が品質保留、四個が別指図へ引当済みなら、Xへ使える数は違います。設備カレンダーに休日が反映されていない場合は、承認画面の完了見込みも誤ります。導入前に、対象ラインで使う品目、部品、ロット、引当、工程、設備、作業者資格、シフト、顧客受注行を小さなデータ台帳にまとめ、更新責任者と遅延許容を決めます。データがない項目は空欄のまま計算するより「判断不可」と示す方が安全です。

現場実績の鮮度は特に重要です。Aが加工を始めた時刻がMESへ遅れて到着すると、APSはAを移動可能だと誤認します。端末の通信断、夜勤の入力漏れ、実績の後日訂正を含めて、変更要求を承認する瞬間に何を最新状態とみなすかを決めます。受信していない実績があり得る設備では、監督者の確認を必須にするという暫定ルールも考えられます。後日訂正で過去の判断を静かに書き換えず、当時の情報と訂正後の情報を対で残します。

部材と能力には「確認済み」と「推定」を分けます。仕入先の納入予定、倉庫入荷、品質検査完了、ラインへのピッキングは別イベントです。設備能力もカレンダー上の空きと、保全が解除され実際に稼働できる状態は違います。試算画面に単一の緑色判定だけを出すと、利用者は前提を見落とします。候補ごとに制約を評価した時刻と不確実な入力を表示し、承認者が代替案を選ぶ材料にします。緊急割込の精度を上げる最初の投資が、アルゴリズムの追加ではなく現場実績とマスタ管理の改善になることもあります。

例外時の人手運用も設計に含める

夜勤でAPSが止まった、MES端末の通信が切れた、顧客から電話が来たが営業責任者に連絡がつかない、といった場面は珍しくありません。緊急対応を止めないため、システム障害時に使う仮の変更票を定義します。票には要求ID、対象設備、旧順序と提案順序、加工中の工程、材料確認、押し出される顧客、暫定承認者、適用時刻、現場への伝達先を必須にします。電話で口頭承認を受けた場合も、誰が誰へ何時に伝えたかを記録し、復旧後に正式履歴へ取り込みます。障害時だから記録を省く設計は、最も説明が必要な変更だけを無証跡にしてしまいます。

手動運用からシステムへ戻すときは、画面上の計画を現場へ一括送信する前に、どの工程が着手・完了・停止したかを再取得します。現場で先に進んだ事実を計画で上書きせず、差分を表示して監督者が照合します。紙の指示と端末の指示が食い違う場合、どちらを優先するかを作業者に判断させないよう、工場が決めた停止・確認手順を用意します。安全に関わる設備停止は、緊急納期より優先するハード制約として扱います。

休日や時差をまたぐ顧客連絡にも責任者が必要です。タイ工場の夕方に日本本社から割込依頼が来て、翌朝の輸出便に影響するなら、誰が顧客約束の変更を承認し、何時までに連絡するかを決めます。通知が送れたことと顧客が合意したことは異なります。未合意のまま工程順序だけ確定させる場合は、そのリスクを承認画面で明示します。

導入ベンダーを比べるときの質問

候補製品のデモでは、きれいなガントチャートより、現場で起きた三つの失敗を再現してもらいます。第一は申請後にBが着手したケースです。古いシミュレーションを承認しようとしたとき、製品が再計算を要求するか、黙って適用するかが分かります。第二は材料引当が他部門で変わったケースです。Xに必要な部品を二重に使わないための検証が見えます。第三はMESへの送信後に応答が返らないケースです。再送が一回だけ適用されるか、現場へ届いたかを誰が確認するかを示せます。

製品比較では「可能」「標準」「設定」「追加開発」を区別してください。たとえば順序のドラッグ操作は標準でも、顧客約束の押出影響は追加開発かもしれません。権限表の設定は標準でも、タイ語の理由コードや現場端末表示には制約があるかもしれません。各要求について、実演した版、必要な前提データ、ライセンス、保守、障害時の運用を記録します。将来の更新時にカスタマイズが維持できるかも確認します。価格だけで比較すると、導入後に現場が使えない承認画面の調整費を見落とします。

最後に、ベンダーの回答を自社の受入条件へ戻します。ある製品が遅延する顧客を直接表示できないなら、ERPの受注行と出荷便を連携して代替できるかを検討します。それでも承認者に影響が見えなければ、要求を満たしたとは言えません。逆に、複雑な全工場最適化がなくても、一つのラインで確実な割込申請、影響提示、承認、現場配信を実現できるなら、最初の導入範囲として有効です。機能の数より、指定した例外を安全に処理できる証拠を優先します。

FATとSATでは「通る案件」だけでなく拒否を試す

FATは構成したシステムが設計した規則どおり動くかを、工場の実機を使う前に検証する場です。SATは実際の設備・端末・ネットワーク・運用者で、現場に反映されるところまで確かめます。用語の使い方は契約で定義してください。合否を「画面が出た」ではなく、入力、期待結果、ログ、責任者で書きます。以下は例で、数値閾値は工場の実績に置き換えます。

SATでは班長と実作業者が画面と紙を見て、次にどの指図を作るかが一致するかを観察します。端末が一台落ちた状態、夜勤への引継ぎ、材料ラベルの読み間違い、タイ語表示、携帯回線への切替も試します。承認ログに「影響なし」と出たときこそ、計算対象外の工程や未更新実績がないかを確認します。1回だけの成功デモではなく、現場の例外を複数日流し、割込件数、承認待ち時間、再計画回数、計画と実績の差を基準値と比較します。

導入順序は一本のラインから始める

最初の段階で全工場の最適化を求めると、未整備の設備能力や部品引当の問題が見えにくくなります。まず割込が多く、顧客影響を測れる一つのラインと製品群を選びます。過去の緊急案件を10〜20件程度、成功・失敗・却下を混ぜて集め、当時の順序、承認、材料、現場状態、納期影響を再構成します。この件数は市場標準ではなく、社内で異なるケースを拾うための初期サンプル例です。データが不足すれば不足自体を記録し、システムで解決できる問題と運用ルールが未定の問題を分けます。

次に、現場状態と時刻を信頼できるようにします。MESに開始実績が30分遅れて入るのに、凍結判定だけ秒単位で行っても意味がありません。指図ID、工程ID、設備ID、材料ロット、顧客受注行の対応を確認し、ERP・APS・MES間の受け渡し表を作ります。並行運用では候補順序を画面へ表示しても現場適用は手動承認とし、紙・電話で決めた従来の結果と差分を記録します。差の原因をデータ、ルール、承認、端末反映に分類してから、自動配信の対象範囲を広げます。

投資効果も「全指図の平均リードタイムが短くなる」と一括りにしません。緊急案件の回答時間、無承認の割込件数、押し出された案件の納期遅延、段取増分、材料探し時間、旧版指示書による手戻りを追います。母数は割込申請件数、対象設備稼働時間、対象受注行などを固定します。効果と副作用を一緒に見れば、緊急案件を早めるために通常案件を恒常的に犠牲にしていないかを判断できます。数週間の実証では季節変動や長期受注の影響まで断定しないことも重要です。

承認一件のデータをどう残すか

監査のために大量の画面キャプチャを保存するだけでは、後から「なぜBを遅らせたか」を検索できません。変更要求を一意のIDで管理し、申請者、理由コード、顧客からの原依頼、対象設備、対象工程、割込指図、押し出される指図、提案した新旧順序、試算時刻、入力データ時刻、ルール版、承認者、適用時刻を構造化した項目にします。自由記述は判断の背景を補うために使い、主要な判断材料は項目として検索可能にします。試算をやり直したら前の試算を消さず、候補版を増やします。最終的にどの候補版が承認され、現場へ届いたかを参照関係で結びます。

材料引当や顧客約束は、別システムで後から変わります。現在値だけを参照するログでは、当時の判断を再現できません。承認時点の重要な値をスナップショットとして残し、元データのIDと時刻も持たせます。例えばBの約束日が後に顧客合意で変わっても、割込承認時にどの約束を見ていたかは失わないようにします。個人名の扱い、保持期間、訂正権限は会社の規程に従って決め、ログの無断削除や一括上書きを防ぐ必要があります。RFPには、監査検索を誰が行い、どの条件で何分以内に結果を取り出すかも書けます。

承認後の取消は、元へ戻すボタン一つで済みません。Xの材料を払い出した後なら返却または別用途への移動が必要です。Bの顧客に遅延連絡済みなら訂正連絡が必要です。MES端末がXの新順序を受け取った後なら、取消版を送って各端末が確認したことを追います。工程開始後なら単なる取消ではなく新たな再計画案件として扱う方が安全な場合もあります。こうした後戻りの境界を状態ごとに定義しておけば、「承認済み」の表示だけが残る不整合を防げます。

生産順序変更の運用指標を設計する

導入後に見る指標は、緊急指図Xが何分早く終わったかだけでは足りません。申請を受けてから実行可否を回答するまでの時間、試算に必要だったデータ補正の件数、承認待ちで期限を超えた案件、現場に配信できなかった案件、押し出された指図の顧客約束違反を分けて測ります。例えば回答が速くなっても、承認後に材料不足で実行できない案件が増えたなら、意思決定の質は改善していません。逆に、割込を断った件数が増えても、断る理由を早く示して顧客と代替日を合意できていれば、業務は改善している可能性があります。

「納期遵守率」だけを比較すると、受注の混み具合や製品構成が違う月を誤読します。割込申請一件を母数にする指標、影響を受けた受注行を母数にする指標、設備稼働時間を母数にする指標を分けます。押し出された指図が元の約束を守れた割合だけでなく、守れなかった場合の遅延幅と顧客への事前通知率を見ます。元の計画がすでに遅れていた案件を割込のせいにしないため、申請直前の予測値と承認後の予測値を保存します。顧客着の実績を取れない場合は、出荷時刻など代替指標を明示し、顧客着と同じ意味で報告しません。

現場負担も測ります。割込による段取回数、段取時間、治具運搬、仕掛の移動、材料返却、旧指示書回収を観察します。現場へしわ寄せを出しながら営業回答だけ速くなっていないかを確認するためです。最初から全てを金額に換算する必要はありません。実績を集める担当と周期を決め、毎週の短いレビューで「どの制約を見落としたか」「どの承認が遅れたか」を一件ずつ確認します。改善策は、入力項目の追加、権限変更、端末表示の修正など具体的な操作へ落とします。

顧客連絡まで含めて割込案件を閉じる

工場内で新順序が適用されても、押し出されたBの顧客が影響を知らなければ案件は完了していません。影響が出る受注行を営業窓口へ自動または手動で割り当て、最初の連絡期限を決めます。連絡文には、社内工程の詳細を全て開示する必要はありませんが、新しい出荷見込み、変更理由の伝え方、代替便や部分納入の選択肢、次の報告時刻を含めます。顧客が代替案を認めた時刻と、社内で計画を確定した時刻も区別します。顧客合意がないと適用できない契約なら、承認ワークフローの必須条件にします。

緊急案件Xの顧客にも、希望時刻と正式に約束した時刻を混同しない説明が必要です。試算では間に合うが材料の品質判定がまだ終わっていない場合、「できる見込み」と「確約」を分けて伝えます。条件が揃ったら正式に約束し、条件が崩れたら再連絡する担当を置きます。システム上では、希望時刻、試算結果、承認時の約束、実際の工場完了、出荷、顧客着をそれぞれ保持します。これにより緊急割込の成功を、単なる設備の開始時刻ではなく、顧客との約束を守れたかで評価できます。

出荷手配や輸送便は工場の外側にありますが、順序変更の判断に不可欠です。Bの製品が一時間遅れても次の便へ載せられるか、追加運賃が必要か、輸出書類の締切に間に合うかを確認します。計算エンジンが輸送まで扱わない場合は、営業または物流担当の確認を承認条件にすればよいでしょう。すべてを一つの製品に詰め込むことより、未確認の条件を見える状態にし、責任者が確認してから現場へ配信することが重要です。

顧客への連絡は一度で終わらない場合があります。設備が再停止し、前に承認した割込案が成立しなくなれば、最新の完成見込みを再計算し、どの連絡がまだ有効かを見直します。案件IDに顧客との通話、メール、代替案、回答期限を結び、営業担当が交代しても経緯を追えるようにします。約束の変更を顧客が受け入れた場合も、単に新しい日付へ上書きせず、元の約束と合意の履歴を保持します。これがなければ、後日納期遵守を分析しても、工場都合の遅延と顧客の希望変更を区別できません。

顧客への影響がないと計算された案件にも確認手順を残します。例えば計算対象外の外注工程、休日の異なる倉庫、輸送会社の集荷締切が漏れていれば、「影響なし」は誤った結論です。承認者には試算の対象範囲と除外条件を示し、一定以上の緊急度や顧客重要度では物流担当による目視確認を求めます。運用開始後は、影響なしと判定した案件からも実際の遅延を抽出し、見落とした制約を翌月のマスタ・ルール改善に戻します。

案件を閉じる条件も明確にします。現場で新順序を確認し、Xが着手しただけでは終了ではありません。Xと押し出された指図の完了、出荷、顧客連絡を照合し、未解決の差分に担当者と期限を付けます。完了した後でも設備停止や品質不良で結果が変われば、同じ案件に追記するか新しい変更要求を発行するかを運用規則で決めます。

事例で見る意思決定：Xを入れてよい場合と見送る場合

仮の例として、Aは加工中、Bは材料を払い出し済み、Cは未準備、Xは顧客ライン停止の恐れがある案件とします。Xの部品は倉庫にありますが、共用治具はBの段取に使っています。候補1はA終了後にXを入れる案で、治具の交換が二回増え、Bの工場完了は遅れるものの出荷便には間に合います。候補2はBまで終えてからXを入れる案で、段取は少ない一方、Xの顧客着が希望時刻に届きません。ここで計画担当は候補1の条件を提示し、資材担当はXの部品ロットの品質状態を確認し、現場監督者はAの加工中に変更を配信しても誤着手が起きないかを確認します。承認者は、Xへの利益とBへの負担を同じ画面で見た上で候補を選びます。

別の結果もあり得ます。Bの出荷便が一日一便で、候補1でも実際にはBの顧客着が翌日になるなら、候補1を自動承認してはいけません。Bの営業窓口が顧客へ代替便や部分納入を確認するまで保留するか、別設備・残業・外注の候補を探します。Xを断ることも合理的な判断です。システムの目的は緊急要求を必ず通すことではなく、通せる条件と通せない理由を短時間で再現可能に示すことです。なおこの事例の時間や工程は説明用であり、設備能力や契約条件の一般値ではありません。

よくある失敗と対処

最優先フラグだけ追加する

フラグは意図の表示にすぎません。材料や能力を再計算せず現場順序だけ変えると、直前で部品不足が判明します。候補表示時に不足理由を明示し、承認時に再検証します。

営業と現場で別の順序表を持つ

営業のExcel、APSの計画、MESの次作業が違うと、誰も有効版を説明できません。正本と配信状態を決め、現場端末の確認時刻まで追います。

凍結を厳しすぎるか緩すぎる設定にする

全日固定では必要な割込を扱えず、制限なしでは段取中や加工中まで動きます。工程状態と例外承認で設計し、実際の却下・例外履歴から見直します。

顧客約束を計画日で上書きする

再計算した完了見込みを約束日へ書き戻すと、遅延が消えたように見えます。約束を保持し、差分を承認と顧客通知へつなぎます。

承認を経てもMESの旧リストが残る

承認は適用ではありません。送信、受信、端末反映、作業者確認、着手を別イベントで記録し、失敗時の責任者を決めます。

FAQ：緊急割込・ディスパッチング優先順位管理

緊急オーダーの割込はAPSだけで管理できますか？

APSが順序候補と影響試算を担えても、現場の開始・停止・材料払出を最新で受け取れなければ、承認した案が実行不能になり得ます。ERPの受注・引当、MESの現場状態、承認ワークフローをどう接続するかを要件にしてください。製品によって一つのシステムで完結する場合も、イベントごとの正本は明示します。

生産順序の変更承認は誰がするべきですか？

一律の役職はありません。押し出される顧客約束、段取や残業、材料、品質・安全への影響を把握できる権限者が必要です。依頼者と承認者は分け、緊急時の暫定権限と追認条件を定義します。承認者が画面で何を見たかも残します。

凍結期間は何時間にすべきですか？

普遍的な時間はありません。工程の開始、材料ピッキング、段取、外注・輸送手配といったイベントで変更禁止を定義し、必要なら時間窓を加えます。過去案件を再生し、止められない作業が保護されるかで決めます。

どのような場合に順序変更ではなく指図変更が必要ですか？

数量、BOM、工程経路、ロット構成そのものを変える場合は、順序の入れ替えを超えます。指図の版管理、分割・統合、品質と原価への影響を別の変更手続で扱い、その結果できた指図を順序計画へ戻します。

RFPでは最初に何をデモしてもらうべきですか？

発行済みのA→B→CへXを割り込ませるケースです。Xに材料競合があり、Bの顧客着が遅れ、Aは加工中という条件を入れます。提案、拒否理由、影響一覧、承認、MES配信、端末確認、通信失敗時の再送まで一続きで見ます。

まとめ

発行後の生産順序変更は、急ぎの一件を前へ動かす操作ではなく、既存の指図と顧客約束をどう守るかの判断です。緊急の定義と権限、凍結条件、材料・能力・仕掛・納期の同時確認、押し出される指図の可視化、ERP・APS・MESの正本、版付き配信と監査を一連の業務として設計してください。RFPとFAT/SATには、成功する割込だけでなく、拒否、同時申請、現場着手、通信断、取消を入れると、導入後に起きる問題を早く発見できます。

タイ工場で緊急割込の現状整理やRFPの試験シナリオを作る段階なら、対象ラインの指図・材料・現場端末・顧客約束を持ち寄ってお問い合わせください。既存システムを生かす前提で、どこに承認と同期の境界を置くかから相談できます。

参考情報

• Oracle: Analysis and Adjustment Using the Dispatch List — 設備ごとの工程順序の確認・変更例。
• Oracle: How You Review a Dispatch List — 現場のディスパッチリストと優先順位表示例。
• Microsoft: Release production orders — 発行後の現場実行と材料ピッキング。
• Microsoft: Operations scheduling — 能力・材料・関連指図を考慮する日程計画。
• Microsoft: Job scheduling — 有限能力・有限材料と工程単位の日程計画。
• Oracle: Schedule Parameters — fixed time fenceと発行済み指図のfirm設定。
• Oracle: Solve and Repair Behavior — firm状態と再計画の扱い。
• Microsoft: Improve scheduling engine performance — 並列日程計画時の資源予約競合例。

*各製品の説明は業務設計の参考例です。権限、閾値、性能、連携方式は導入先の契約・設備・データで確認してください。*