製造業の在庫引当管理システム導入｜受注確約から再配分まで

製造業で在庫引当管理システムの導入を検討するとき、最初に確認すべきなのは「在庫数を表示できるか」ではありません。同じ在庫を複数の受注へ約束しないこと、約束した数量を出荷まで追えること、変更や取消時に利用可能数へ正しく戻せることです。帳簿上は十分な在庫があるのに、営業が回答した納期を倉庫が守れない。反対に、特定顧客向けに取り置いたまま使われない在庫が残る。こうした問題は、在庫精度だけでは説明できません。本記事ではタイ・ASEANの工場を想定し、受注行、製造ロット、倉庫作業をつなぐ引当の状態設計、ERP・WMS・MESの役割、RFPからFAT・SATまでの確認方法を整理します。

在庫引当管理システムで決めるべきこと

在庫引当は、単なる「現在庫－受注数」の計算ではありません。ある品目・拠点・利用可能状態・必要日について、どの需要がどの供給を使う権利を持つかを決め、その権利を変更・取消・出荷まで追跡する業務です。受注残の全体像を見る業務とは異なり、引当は個々の受注行に対する供給の占有と解除を扱います。受注残の年齢や納期回答の会議体は、製造業の受注残管理で整理しています。ここでは「今、この注文に約束した数量の根拠は何か」に絞ります。

引当システムの提案を比較する前に、少なくとも五つの問いを一枚の業務図に書き出します。第一に、受注入力時点で確保するのか、承認後か、出荷指示時か。第二に、現物在庫のみを対象とするのか、発注済み・製造予定の供給も含めるのか。第三に、品目だけでなく、サイト、倉庫、在庫ステータス、ロット、有効期限、顧客指定品をどの粒度まで固定するのか。第四に、取消、数量減、優先顧客への付替え、品質保留で誰が解除を承認するのか。第五に、引当の正本と倉庫の現物移動をどのイベントで一致させるのか。これらが未決のまま「リアルタイム在庫対応」の機能表だけを比べても、運用結果は比較できません。

Microsoft Dynamics 365の文書は、販売注文に対する予約を自動または手動で実行でき、予約済み数量は一部または全部を解除しない限り他の注文へ払い出せないと説明します。また、現物在庫と未入荷の発注済み在庫を区別しています。この製品仕様を他社製品の標準動作とみなすのではなく、RFPで「自社の引当対象と時点をどう扱うか」を問うための参考にします。出典：Microsoft「Reserve inventory quantities」。

「配分枠」と「受注への引当」は同じではない

不足が見込まれる部材を、顧客群Aへ一定量、顧客群Bへ別の量として事前に割り振る。この段階では個別の注文がまだ存在しない場合があります。これはチャネル・顧客群・地域などへの配分枠です。一方、実際の受注行が入った後に、その注文へ数量を結び付けるのが受注引当です。Microsoft Inventory Visibilityの文書も、allocationは注文成立前の仮想的な枠であり、soft reservationは実際の販売トランザクションに結び付くことが多い、と区別しています。同文書は両方使う場合、配分後に引当する順序を推奨しています。出典：Microsoft「Inventory Visibility inventory allocation」。

ここを混同すると二つの事故が起きます。配分枠だけを見て「注文Aの納期は確約済み」と営業が判断すれば、枠の中で複数の注文が競合します。逆に注文行の引当だけを作り、重要顧客や保守用の供給枠を事前に保護しなければ、先着注文がすべて使い切る可能性があります。どちらを使うかは優先順位ポリシーによります。標準在庫、契約顧客向け、試作・保守向けなどを同じ「取り置き」列で表現せず、配分枠IDと受注引当IDを別に持たせます。

例として、ある部材の販売可能在庫が100個、契約顧客群向け配分枠が40個、一般向けが60個だとします。契約顧客の受注Aが15個を要求すれば、契約枠の残25個と注文Aの引当15個を別々に追跡します。この100・40・60・15は説明用の仮定値です。実運用では品質保留、先約、単位換算、ロット制約を先に反映し、販売可能数を確定しなければなりません。枠の消費と注文引当を両方総在庫から単純に差し引けば二重減算になるため、計算式とイベントの所有者を設計書に明示します。

利用可能数を一つの数字に押し込めない

「現在庫100個」は、顧客に100個を約束できる意味ではありません。検査待ち、品質保留、他受注への引当、出荷済み未計上、棚卸差異、別倉庫の在庫、顧客指定ロットの不一致を考慮します。さらに、今日出荷できる数量と来週製造して出荷できる数量は別です。画面には少なくとも現物数量、出荷可能数量、引当済数量、未引当の出荷可能数量、入荷・完成予定数量、約束可能日を区別して示します。「販売可能」「引当可能」「ATP」を同義語として一つのフィールドに置くと、営業・生産・倉庫が異なる意味で同じ数字を使ってしまいます。

ATP（available to promise）は納期回答のための供給と需要の評価です。OracleのATPルール文書では、対象となる供給を現物、購買発注、製造作業指図などから定め、どの需要へ充当できるかを設定すると説明しています。出典：Oracle「Available-to-Promise Rules」。したがって「ATPがある」と「倉庫で現物を確保した」は別の状態です。将来供給を使って納期を回答する場合は、入荷遅延・製造遅延の時に約束を再評価し、対象注文へ通知する責任者も決めます。

設計で使う数量の例は、現物可用数量＝現物在庫－品質・安全上の使用不可数量、未引当可用数量＝現物可用数量－有効な現物引当数量、将来日付の約束候補＝未引当可用数量＋その日までの確実性を評価した供給－先行需要、という順で分けられます。ただしこれは説明のための単純な式で、実際の算定式は製品仕様、在庫ディメンション、引当優先順、消費タイミングに依存します。未来の発注数量をすべて「確実」と扱う実装は避け、購買発注の確認状況や工程能力に応じて回答ルールを定めます。

引当可能数の更新イベントを列挙する

受入確定、品質判定、移動、棚卸調整、受注作成、引当、解除、ピッキング、出荷確定、返品受入、製造完了、スクラップは、すべて利用可能数を変える候補です。各イベントについて「発生元」「イベントID」「対象品目・拠点・ロット」「数量」「時刻」「二重受信時の処理」「取消時の逆イベント」を表にします。遅延や再送があっても同じ取引を二重に計上しない冪等キーを用意します。会計上の在庫更新と、顧客へ約束できる数量の更新が同じ時刻とは限らないため、遅延の許容範囲を業務ごとに決めます。

Microsoft Inventory Visibilityのsoft reservation例では、複数の受注チャネルが共通の引当可能数を照会し、成功時にsoft reservedを増やし、available for reservationを減らします。注文がERPへ移りhard reservationになる際にはsoft reservationを相殺する仕組みも説明されています。ここから得るべき設計上の教訓は、チャネルが複数なら共通の競合制御点を定め、仮引当から確定引当へ移る際に二重計上を防ぐことです。出典：Microsoft「Inventory Visibility reservations」。

受注から出荷までの状態遷移を設計する

状態名を増やすだけでは運用は安定しません。各状態へ入る条件、出る条件、権限、数量変更の方法、監査ログを定義します。次の表はRFPの叩き台です。製品固有の標準状態名ではなく、自社業務の概念として読んでください。

部分引当と複数納期を正常系として扱う

一つの受注行が100個を要求し、今日50個、来週30個、残り20個の納期が未定という場合を考えます。注文全体へ単一の「引当済」フラグを付ければ、営業は100個すべてが確保されたと誤解します。受注行を供給の明細へ分け、数量と約束日をそれぞれ保持します。「50個は現物で確定」「30個は製造完了予定に依存」「20個は未確約」と表示すれば、顧客への回答と工場への手配を一致させやすくなります。この数値も説明用の仮定値です。部分出荷、代替品、工場間移管、受注変更がある業態では、約束履歴を上書きせず改訂番号を残します。

受注数量を減らしたときは、どの供給明細から解放するかを決めます。単純に末尾の予定分から戻すのか、顧客がキャンセルした特定納期の分を戻すのかで、別注文への再配分可能日が変わります。数量を増やしたときは元の引当を壊さず増分だけ評価し、成功しなければ「既確約分は維持、増分は未確約」と示します。すべてを一度解除して再取得する方式は、競合中の他注文に先約を奪われるリスクがあるため、採用する場合はトランザクション境界を確認します。

期限切れ仮引当と取消のルール

見積やWeb注文で仮引当を使うなら、有効期限を明示します。期限切れで自動解除する際、決済・受注承認が遅れて到着した場合の扱いも必要です。「解除した後で承認が来た」事象を正常系としてテストします。取消は元イベントを削除するより、理由・時刻・担当者を付けた逆操作として記録すると追跡しやすくなります。部分取消と全取消の違い、ピッキング開始後の取消、出荷確定後の返品を同じ解除APIに押し込まず、段階に応じた承認と現物確認を設けます。

ロット・場所はいつ固定するか

受注時に「倉庫から10個」を約束できても、その時点で棚番やパレットまで固定する必要があるとは限りません。倉庫の波動ピッキングや先入先出の運用を生かすなら、受注ではサイト・倉庫・在庫ステータスまでを固定し、具体的な場所やライセンスプレートはWMSが作業時に選ぶ設計が考えられます。一方、顧客が特定ロット、シリアル、有効期限、試験成績書を指定する場合は、その条件を受注・引当へ早い段階で結び付けなければなりません。

Microsoftの倉庫レベル予約ポリシー文書は、需要側がサイト・倉庫・在庫ステータスなど必須のディメンションを持ち、倉庫側が場所を決める階層と、顧客条件によりバッチやシリアルを需要側で先に固定する階層を区別しています。出典：Microsoft「Flexible warehouse-level dimension reservation policy」。自社で必要な固定粒度を超えて細かく引当すると、棚移動のたびに解除・再引当が発生します。逆に粒度が粗すぎると、倉庫がピックした現物が顧客条件を満たさない可能性があります。ロット追跡が必須なら、代替ロットの承認と顧客通知も状態遷移に含めます。

倉庫作業の読取タイミングや入出庫実績との関係は、ハンディ端末と在庫システムの連携で扱っています。本記事の焦点は、端末で読んだ現物がどの受注引当に対応するか、誤ピック時にどこへ差異を戻すかです。端末のスキャンだけを成功条件とせず、引当ID、ピック明細、出荷明細を結合して追えることを検収します。

ERP・WMS・MESの権限を一つずつ決める

「ERPもWMSも在庫を持つ」こと自体は問題ではありません。問題は、同じ引当可能数を別々のルールで更新し、どちらが正しいか決められないことです。ERPは受注、顧客条件、会計・計画の主記録を持ち、WMSは保管場所、ピッキング、実際の倉庫移動を扱い、MESは製造指図、工程投入、完成実績を扱う、という役割分担を起点にします。ただし既存環境でシステムの責任範囲が異なるなら、製品名に合わせずイベントごとに正本を指定します。

もし受注チャネルが複数あり、どれも在庫を即時に確約するなら、共通の引当サービスか、一つのシステムを経由した原子的な判定が必要です。チャネルごとのローカル在庫コピーに対してそれぞれ引当を確定すると、最後の一点を二重販売し得ます。ネットワーク断のときに「注文を受け付けるが納期は未確約」とするのか、受付を止めるのかを業務側が選びます。後で同期すればよい、という曖昧な仕様では顧客への約束を管理できません。

仮引当から確定引当への二重減算を避ける

ECや営業端末で仮引当した注文がERPへ登録され、ERPで確定引当へ進むとき、仮引当を残したまま確定分を追加すれば同じ注文が二重に在庫を占有します。反対に仮引当を先に解放してからERPの確定処理を始めると、その隙間で別注文が取得する恐れがあります。連携キーと状態移行を一組にし、「仮を相殺し確定へ移す」処理の成功・失敗・再送を設計します。元注文IDと行ID、引当ID、供給明細IDを結び、同じメッセージの再送で二度消費しないことをFATで確認します。

MESから完成実績が来る場合も、「完成予定を供給候補へ入れていた」「実績が確定した」の二つを重複加算してはいけません。予定供給を実績へ置き換えるタイミング、検査合格前に販売可能へ入れるか、ロット確定後にどの注文へ引き当てるかを決めます。WMSから出荷済みの通知が遅れている間にERP側で現物引当を解除すると、まだ倉庫で作業中の数量を別注文へ約束する恐れがあります。処理順序と保留状態を見える化します。

引当解除・再配分を日常運用として設計する

取消や納期変更は例外ではなく、継続的に起こる業務です。引当解除を管理者の裏画面だけに置くと、営業は正しい在庫を使えず、倉庫は実態のない取り置きを抱えます。解除理由を「顧客取消」「数量減」「期限切れ」「品質保留」「優先順位変更」「在庫差異」「代替品採用」などから選択し、元の約束日、承認者、通知先を残します。解除後に自動で次の注文へ渡すのか、人が優先順位を確認するのかを品目群ごとに決めます。

再配分の公平性には、先着順だけでなく契約義務、ライン停止リスク、輸出便の締切、顧客指定ロット、粗利などが関わり得ます。ただしすべてを一つのブラックボックス点数にする必要はありません。まず「手動上書きしてはいけない制約」と「担当者が理由付きで変更できる優先順位」を分けます。システムは候補を提示し、変更前後の影響注文、減る数量、約束日の変化を示します。顧客に一度通知した確約を外す場合は、単なる在庫再計算ではなく営業承認と通知履歴を必須にします。

品質保留と棚卸差異が起きた場合

品質部門がロットを保留にした瞬間、そのロットを使う予定だった受注行を特定できる必要があります。引当を自動で解除するのか、一旦「例外保留」にして代替候補を提示するのかは、顧客条件と現場権限で変わります。保留の解除前に別ロットへ付け替えた場合、元ロットが再び販売可能になった時に二重の約束が残らないようにします。棚卸差異でも同じです。実在庫が帳簿より少ない場合、どの引当を守り、どの注文へ納期再回答を求めるか、規則と承認ログが必要です。

欠品を隠すための負在庫許可は慎重に扱います。負在庫が必要な業務が存在しても、受注引当と現物払出しで同じ許容ルールを使うとは限りません。現物が足りないことを許して注文を記録するなら、顧客への納期は「未確約」と区別し、どの供給で充当するかを後続の作業に残します。例外を正常な在庫として見せる運用は、システムを導入しても二重約束を見えにくくするだけです。

導入方式は状態と責任で比較する

パッケージ、既存ERPの追加機能、WMS連携、独立した引当サービス、個別開発のいずれを選ぶにしても、機能一覧の丸印だけで比較しないことが重要です。製品が「引当対応」と書いていても、現物のみ、発注残も含む、ロット固定可能、部分引当可能、複数サイト横断可能などの範囲は異なります。まず自社の品目群を、量産標準品、顧客専用品、期限管理品、保守部品、試作品などへ分け、それぞれに必要な引当粒度と解除権限を定義します。

既存ERPが受注と在庫の正本なら、その標準予約機能を優先的に検証します。ただし複数のチャネルが高速で同時に注文を取り、ERPへ遅れて同期する場合は、共通の仮引当レイヤーの要否を検討します。WMSが現物ロット・場所の正本なら、ERPが棚番まで無理に固定するより、顧客条件を渡してWMSがピック可能な現物を決めるほうが運用に合う場合があります。MESが将来供給の見込みを出す場合は、確定した製造完了との区別を連携設計に含めます。

見積比較では、ライセンス・開発費だけでなく、マスタ整備、連携改修、端末作業変更、教育、例外監視、保守、将来の拠点追加を同じ範囲で揃えます。「既存システム連携込み」という表現だけでは、どのイベントを誰が実装するか不明です。費用の比較可能性を上げるには、業務イベントと受入条件を先に共通化します。

RFPに書くべき業務シナリオとデータ

RFPでは、ベンダーに「引当機能の有無」を尋ねるより、同じシナリオを同じデータで動かしてもらいます。対象品目の単位、倉庫、ロット、有効期限、在庫ステータス、受注行、希望日、供給予定を匿名化したサンプルで渡します。最低限、次のシナリオを含めます。

1. 同時に二つのチャネルから最後の在庫を要求し、片方だけを確約する。
2. 顧客群の配分枠を設定し、その枠内で二件の受注へ部分引当する。
3. 現物不足分を将来供給で回答し、製造遅延で約束日を再計算する。
4. 一部数量を取消し、他注文への再配分候補を表示する。
5. 顧客指定ロットが品質保留となり、代替ロットの可否と承認を扱う。
6. WMSのピック結果が要求ロットと違う場合、出荷を止めて差異を戻す。
7. ERP連携メッセージを重複送信し、引当数量が二重に増減しない。
8. ネットワーク断から復旧した後、仮引当の期限切れと遅着承認を照合する。

各シナリオに入力、期待される状態遷移、画面に見える数量、出力イベント、ログ、権限、失敗時の戻し方を指定します。ベンダー回答には「標準」「設定」「追加開発」「対応不可」「代替運用」を分け、画面デモとAPI・データ項目の証拠を求めます。ロットと保管場所の予約階層、将来供給の扱い、配分枠と引当の関係は、製品による差が大きいため、曖昧な回答を残さないことが重要です。

FATとSATで検証する境界

FATではテスト環境で状態と連携のロジックを確認します。二重確約防止、部分引当、解除、再送の冪等性、権限、監査ログを重点とし、成功時だけでなく、通信タイムアウト後に相手側で処理が完了したケースも再現します。画面表示が正しくても、裏側で数量が二重減算されるなら不合格です。対象品目・拠点・ロット単位で、操作前後の数量を照合します。

SATでは実際の受注入力、倉庫のハンディ端末、ピックと出荷、品質保留、MES実績、担当者の承認と顧客通知までを通します。タイ現地の担当者が使う言語、時刻・日付形式、シフトをまたぐ作業、ネットワーク断、外部倉庫からの連携も確認します。FATで通ったAPIが、現場のラベルやロット運用に合わなければ出荷は止まります。合否を「担当者が使いやすい」という感想だけでなく、期待した引当ID・数量・履歴が残る証拠で判定します。

移行時の未完了受注と既存の取り置き

稼働前に移すべきなのは在庫残高だけではありません。未出荷の受注行、先行して通知した約束日、手作業の取り置き、品質保留、発注済み供給、製造予定、顧客指定ロットを棚卸しします。過去のExcelに「予約済み」とだけ書かれた行は、受注IDに紐づく確約なのか、顧客群の配分枠なのか、単なる営業メモなのかを分類します。分類できない数量を無条件で確定引当に移すと、初日から利用可能数が歪みます。

切替前後の照合表には、品目・拠点・ロット・在庫状態別に、現物、保留、配分枠、仮引当、確定引当、未確約受注を分けて載せます。差分が出たときの承認者と修正期限を決め、旧システムをいつ読み取り専用にするかも明記します。切替初日の新規注文だけ成功しても、移行した先約が消えていれば導入は成功ではありません。

運用KPIは「約束の質」を測る

在庫精度や棚卸差異に加え、引当の運用では、確約後の納期変更件数、二重確約件数、期限切れ仮引当の滞留件数、解除から再配分までの時間、例外保留の未処理件数、引当とピックの不一致件数を見ます。比率を出すなら分母を、全受注行、確約済み受注行、対象品目群のどれにするか固定します。数値目標は自社の現状を測ってから設定し、外部の汎用的な改善率を無条件に当てはめません。

現場に負担をかけないため、すべての受注を同じ細かさで管理する必要はありません。納期違反の影響が大きい顧客専用品、供給が不安定な部材、期限・ロット制約が厳しい品目から始める方法があります。初期対象の境界を狭くする場合でも、後から品目や拠点を増やすためのコード体系、イベントID、監査ログ、権限設計は最初から揃えます。状態の意味を部署間で共有し、例外処理の担当者を決めることが、画面機能の追加より先です。

よくある質問

在庫引当管理と在庫管理システムはどう違いますか？

在庫管理は現物が「何を、どこに、いくつ」あるかと移動履歴を扱います。在庫引当管理は、そのうちどの数量をどの受注・需要へ約束しているか、いつ解除できるかを扱います。一つの製品に両機能があっても、数量の正本とイベントの境界を別に定義する必要があります。

配分枠だけで受注の納期を確約できますか？

通常は配分枠だけでは個々の注文への約束を証明できません。枠は顧客群などへ供給を事前に割り振る概念です。受注行の数量・希望日・制約を確認し、枠から引当へ移す処理とその記録が必要です。製品ごとに用語が異なるため、RFPでは実際の状態遷移を確認します。

引当解除後、在庫はすぐ他の受注に使えますか？

業務状態によります。倉庫でまだピックしていない現物なら、解除後に他注文へ回せる場合があります。作業中、品質保留、出荷確定後は、WMSの作業取消や返品の確定が先です。システム画面で解除しただけで現物が販売可能になったとみなす設計は避けます。

ERPとWMSのどちらで引当を持つべきですか？

受注への確約、場所・ロットの現物選択、出荷実績を分けて判断します。受注を持つERPや共通引当サービスが確約を管理し、WMSがピック対象の現物を決める構成は一例です。既存製品の標準機能、チャネル数、ロット制約、遅延許容を確認して正本を定めます。

導入前に最初に用意する資料は何ですか？

代表品目について、未完了受注、現物・保留在庫、手作業の取り置き、将来供給、顧客への約束日を並べた一覧を用意します。そのうえで、受注登録から出荷までの状態、変更・取消の担当者、ERP・WMS・MES間のイベントを書きます。この資料がRFPと受入テストの共通基準になります。

まとめ：在庫の数字より約束の状態を先に定義する

製造業の在庫引当管理システムは、配分枠、ATPによる回答候補、受注への仮・確定引当、倉庫作業、出荷による消費、解除・再配分を一つの流れとして扱って初めて役立ちます。導入の出発点は、対象品目の約束ルール、数量の正本、状態遷移、例外時の責任を決めることです。その設計を同一シナリオでベンダーへ提示し、FAT・SATで数量と履歴を確認すれば、機能名だけの比較から抜け出せます。

TOMAS TECHでは、タイ工場の受注・在庫・倉庫・生産のつながりを確認し、引当と解除の業務図、RFPのシナリオ、既存システムとの責任分担を整理する段階からご相談いただけます。在庫引当管理の導入相談はこちらをご覧ください。

参考情報

• Microsoft Learn: Reserve inventory quantities
• Microsoft Learn: Inventory Visibility reservations
• Microsoft Learn: Inventory Visibility inventory allocation
• Microsoft Learn: Flexible warehouse-level dimension reservation policy
• Oracle Supply Chain Planning: Available-to-Promise Rules