欠品防止システム2026｜在庫・発注点・例外対応の5層設計

工場の欠品防止システムを検討するとき、最初に比較されがちなのは在庫アラート、発注点計算、ダッシュボードの機能です。しかし、画面上の赤い警告を増やすだけでは、欠品は減りません。欠品を継続的に抑えるには、正確な手持在庫、需要・消費、補充リードタイム、安全在庫方針、例外の担当者、発生後のパラメータ見直しを一つの制御ループとしてつなぐ必要があります。

本稿は、タイ・ASEANの工場長、調達責任者、生産計画担当者、IT責任者が、ベンダー比較やRFP作成を進めるための実務ガイドです。単なる「在庫管理の見える化」ではなく、欠品を予防し、発生時に早く収束させ、次の欠品を減らす仕組みを、5層設計、補充方式の選定、RACI、90日パイロット、受入試験、ROI/TCO試算まで落とし込みます。

エグゼクティブサマリー：欠品防止は5つの制御を閉じる仕事

結論から言えば、良い欠品防止システムは次の5層を循環させます。

1. 実在庫を正しく捉える：品目・ロケーション別の入出庫、移動、保留、仕掛、棚卸差異を記録する。
2. 将来の不足を予測する：需要、消費、生産計画、確定受注、補充リードタイムを時間軸で突き合わせる。
3. 補充ルールを実行可能な提案に変える：発注点、Min/Max、MRP・予測の適用範囲を分け、数量と期日を提示する。
4. 例外を担当者と期限に結び付ける：アラートを担当、優先度、判断期限、代替案、承認に変換する。
5. 結果を検証しパラメータを直す：欠品原因、回避可否、納期実績、需要誤差、在庫差異を振り返り、閾値を更新する。

欠品対策のRFPでは「画面があるか」ではなく、「イベント発生から判断、実行、記録、改善までが閉ループになっているか」を受入試験で確かめるべきです。システム導入の前後で、欠品件数だけでなく、重要品目のカバー率、在庫精度、例外処理時間、緊急輸送費、火消し工数、パラメータ見直し完了率を追います。

なぜ在庫があるのに欠品するのか

欠品は「倉庫に物がゼロ」という単純な現象とは限りません。帳簿上は100個あっても、実物が別ロケーションにある、品質保留中で使えない、必要なラインへ間に合わない、ロットや仕様が合わない、システム反映が遅れているなら、生産にとっては欠品です。

1. 手持在庫の数字が実態とずれる

入荷未計上、払い出し後の未記録、誤ロケーション、単位換算ミス、廃棄・不良の未反映、仕掛在庫の停滞などが積み重なると、発注点計算の入力が崩れます。バーコードやRFIDは正確な取得を助けますが、識別ルール、スキャンの実施点、例外時の処理、マスタ統制がなければ精度は保証されません。GS1 General Specificationsは、識別とデータキャプチャの共通基盤を示しますが、技術導入だけで業務精度が自動的に成立するわけではありません。

2. 「平均需要」だけで発注点を置いている

平均日次消費×平均リードタイムだけでは、需要のばらつき、納入遅延、最小発注量、休日、輸送便、検査時間を吸収できません。逆に、すべてを厚い安全在庫で覆えば、滞留・陳腐化・キャッシュ拘束が増えます。安全在庫は不安の大きさではなく、品目の重要度、需要変動、供給変動、目標サービスレベル、代替可能性を基に決める必要があります。

3. 需要・生産計画と在庫が別々に更新される

販売計画が月次、生産計画が週次、在庫が日次、購買納期がメールの中という状態では、どの時点の数字で補充判断したか分かりません。特に、生産計画の前倒し、BOM変更、歩留まり悪化、顧客の特急注文が起きたとき、在庫アラートだけでは将来不足を捉えきれません。

4. アラートの責任者が決まっていない

「不足見込み」という通知が20人に届いても、誰も意思決定者でなければ対応は進みません。調達は需要変更待ち、生産管理は納期回答待ち、倉庫は在庫確認待ち、品質は代替材承認待ちになり、警告だけが古くなります。例外にはオーナー、回答期限、エスカレーション先、選択肢、承認記録が必要です。

5. 欠品後にパラメータを直していない

緊急輸送でその場をしのいでも、リードタイム、発注点、安全在庫、発注ロット、サプライヤー条件、棚卸頻度を見直さなければ再発します。欠品イベントを「誰かのミス」で閉じず、原因コードとデータを残し、回避可能だったかを判定してルールへ戻す必要があります。

在庫の入出庫・ロケーション統制を広く比較したい場合は、WMS比較ガイド2026も併せて参照してください。MRPの結果が安定しない場合は、先にMRPシステムとマスタデータ精度で品目、BOM、リードタイム、ロットの前提を点検する方が近道です。

欠品防止システムの5層制御ループ

5層は別々のモジュールではなく、前の層の出力が次の層の判断材料となり、最後の結果が最初の入力精度とパラメータへ戻るループです。RFPでは、層ごとの機能一覧だけでなく、層をまたぐデータと責任の接続を確認します。

第1層：実在庫 — 「使える数量」を時点付きで確定する

最低限必要なのは、品目×拠点×倉庫×ロケーション×在庫状態の粒度です。オンハンド、引当済み、品質保留、仕掛、移動中、入荷予定を混ぜて一つの「在庫数」にしないことが重要です。生産に使える数量は、単純な帳簿残ではなく、利用可能在庫として定義します。

主な統制は以下です。

• 入荷、格納、移動、払い出し、返品、廃棄、調整のイベント時刻と実行者を残す。
• 負在庫を原則禁止し、例外許可には理由と承認を求める。
• 重要品目はサイクルカウントを頻度別に計画する。
• 棚卸差異が閾値を超えたら、承認前に取引履歴とロケーションを照合する。
• 在庫スナップショットに「何時時点か」「最終更新イベントは何か」を表示する。

Microsoft Dynamics 365のサイクルカウント資料は、計画または閾値に基づく循環棚卸と、差異のレビューという考え方を示しています。製品固有の設定をそのまま採用するのではなく、自社の重要度分類と承認統制に置き換えて要件化します。

第2層：需要と時間 — 不足する「日」を見つける

欠品防止では、現在残高よりも将来の在庫推移が重要です。日別またはシフト別に、初期利用可能在庫、確定入荷、計画入荷、確定需要、予測需要、従属需要、引当、品質保留解除を並べ、予測利用可能在庫が安全在庫やゼロを割る時点を算出します。

ここで必要なのは数字の出所です。需要が販売予測なのか確定受注なのか、生産計画なのか、補修予約なのかを区別します。変更履歴も残し、「昨日は不足していなかったのに今日不足した理由」を追えるようにします。リードタイムも固定値一つではなく、発注処理、供給者製造、輸送、通関、受入検査、格納の内訳を持つと改善しやすくなります。

第3層：補充方針 — 品目特性に合う方式を適用する

すべての品目に同じ補充ロジックを適用しません。安定消費品には発注点、棚やかんばんで上限・下限を管理する品目にはMin/Max、BOM従属需要や変動の大きい完成品にはMRP・予測連動が向きます。方式は品目分類とセットで管理し、担当者が無断で切り替えられないようにします。

SAPのReorder Point Planningでは、発注点が補充リードタイム中の期待需要を覆い、安全在庫が超過消費や納入遅延を吸収する考え方が示されています。また履歴、サービスレベル、リードタイム、予測誤差を用いた自動計画が説明されています。Oracle Fusion CloudのMin-Max Planningは、在庫ポジションが最小値を下回ったときに補充を提案する枠組みを示します。いずれも、自社のデータ品質と運用責任を前提に設計する必要があります。

Microsoft Dynamics 365のSafety Stock Fulfillmentでは、安全在庫を最小在庫の目標として扱い、閾値を割る前に計画オーダーで補充できる考え方が説明されています。製品ごとの実装差はあっても、「欠品してから補充」ではなく、時間軸上で目標を守るというRFP要件に置き換えられます。

第4層：例外処理 — 警告を意思決定タスクに変える

アラートには最低でも、品目、欠品予測日、影響する製造指図・顧客、現在の不足量、推奨補充量、最遅発注日、原因候補、担当者、期限を持たせます。担当者は、通常発注、前倒し、分納、代替材、他拠点移送、生産順序変更、需要調整などから対応を選び、根拠を記録します。

重要なのは、アラート数ではなく「期限内に判断された例外の割合」です。重複アラートを束ね、同じ品目・同じ原因の更新は一つのケースに追記します。優先順位は品目単価だけでなく、ライン停止、顧客納期、代替可否、安全・品質影響、復旧時間で決めます。

第5層：学習と統制 — 欠品イベントをルール更新へ戻す

欠品、ニアミス、緊急輸送が発生したら、原因を少なくとも「在庫差異」「需要急変」「計画変更」「供給遅延」「品質保留」「マスタ誤り」「実行遅れ」に分類します。イベントごとに、回避可能性、検知時刻、初動時刻、収束時刻、影響、採った対応、恒久対策を記録します。

月次レビューでは、発注点や安全在庫を一括して増やすのではなく、原因別に処置します。在庫差異なら取得プロセス、供給遅延ならリードタイム分布と供給者対応、需要急変なら予測・顧客情報、実行遅れならワークフローと権限を直します。SAPのSafety Stock and Buffer SimulationやOracle 26CのMulti-echelon Inventory Optimizationが扱うように、サービスレベル、需要変動、リードタイム変動を考慮する高度化も可能ですが、まず実績データと変更統制を整えることが前提です。

発注点管理システム、Min/Max、MRP・予測をどう選ぶか

方式選定は「どれが最も高度か」ではなく、「需要の性質、補充制約、データの成熟度に合うか」で決めます。

実務では混在が普通です。たとえば450の重要品目のうち、定常消費のボルトは発注点、ラインサイド容器はMin/Max、専用部材はMRP、需要変動の大きい完成品は予測連動と分けます。品目ごとに「方式」「設定根拠」「所有者」「最終見直し日」を持たせます。

発注点の考え方

概念上、発注点は「補充リードタイム中の期待需要＋安全在庫」です。ただし計算値をそのまま採用せず、発注単位、最小発注量、発注曜日、運送便、保管容量、賞味期限・有効期限を反映します。安全在庫は、平均値からのぶれをどこまで吸収するかという方針です。目標サービスを上げれば在庫も増え得るため、重要度別に決めます。

Min/Maxの考え方

Minは警戒線、Maxは補充後の目標上限です。在庫ポジションを「手持＋確定入荷−引当」で定義し、Min未満ならMaxまでの差を発注倍数に丸めます。棚容量や保管規制がある場合は、Maxが物理上限を超えない受入試験が必要です。

MRP・予測連動の考え方

MRPは将来の生産計画とBOMを使うため、計画変更に追随できます。一方、BOM数量、歩留まり、代替、リードタイムが誤っていれば、精密に誤った提案を出します。予測連動は需要誤差を前提とし、誤差指標と上書き履歴を同時に管理します。どちらもブラックボックス化せず、提案数量の根拠を担当者が説明できることを要件にします。

在庫管理の見える化に必要なデータとマスタ

ダッシュボードの色より、定義の一致が先です。RFPでは次のデータ項目について、正本、更新頻度、責任部門、品質チェック、連携失敗時の扱いを記載します。

在庫精度を一つの平均値だけで見ない

全品目の平均在庫精度が高くても、重要品目だけずれていれば欠品は止まりません。品目重要度、ロケーション、取引種類、差異理由別に分解し、450の重要品目については別KPIを持ちます。数量一致率だけでなく、正しい場所、状態、ロット、時刻で使えるかを確認します。

連携遅延と失敗を見える化する

ERP、WMS、MES、購買ポータル、表計算をつなぐ場合、最終成功時刻、未処理件数、再送状態、重複排除キーを監視します。リアルタイム在庫管理を名乗っていても、購買納期が翌日バッチなら、補充判断全体はリアルタイムではありません。各データの許容遅延を業務要件として定義します。

マスタ変更は承認と有効日を持たせる

発注点や安全在庫の変更には、変更前後、理由、根拠期間、提案者、承認者、有効日を記録します。大量更新は影響品目数と在庫価値の試算を出し、ロールバックできるようにします。異常値を自動提案する機能があっても、重要品目の本番反映には人の承認を残します。

例外ワークフローとRACI

欠品予防は部門横断です。システムは通知先を増やすのではなく、判断権限を明確にします。以下は出発点となるRACI例です。Rは実行責任、Aは最終説明責任、Cは協議、Iは共有を表します。

例外ケースに持たせる情報

一つのケースに、検知時刻、欠品予測日、影響対象、推奨策、担当者、期限、判断、承認、実行結果、原因コードを持たせます。チャットやメールで相談しても、最終判断はケースへ戻します。これにより、火消し速度と再発防止の両方を測れます。

エスカレーションを時間と影響で決める

「重要」という主観ではなく、ライン停止までの残り時間、顧客納期、代替可否、影響額の区分でレベルを決めます。たとえば、次のシフトに影響し代替なしなら工場長へ、5営業日以上先で通常発注が間に合うなら計画担当で処理する、といったルールです。閾値自体は各工場の稼働と権限に合わせます。

90日パイロットの進め方

全品目・全拠点を一度に切り替えるより、重要品目と一つの業務範囲で制御ループを実証します。パイロットの目的は、デモ画面を確認することではなく、実データと実担当者で欠品予防の受入条件を満たすことです。

0〜15日：基準線とスコープを固定する

• 対象を1工場、1倉庫、代表ライン、450重要品目などに限定する。
• 過去12か月の欠品、緊急輸送、棚卸差異、補充実績を可能な範囲で整理する。
• 欠品の定義、重要度、在庫状態、利用可能在庫を合意する。
• ERP/WMS/MES/購買データの正本と更新頻度を確認する。
• KPIの基準線と測定方法を承認する。

16〜30日：データ整備と補充方式の分類

• 品目、単位、ロケーション、供給者、リードタイム、ロットを検証する。
• 発注点、Min/Max、MRP・予測の適用区分を決める。
• 重要品目のサイクルカウントを実施し、差異理由を記録する。
• 連携失敗、重複、遅延の監視を設定する。
• RACIと例外SLAを確定する。

31〜60日：シャドー運転

システムの補充提案を出す一方、既存判断をすぐには止めません。提案差、欠品予測の早さ、誤警報、見逃し、担当者の判断時間を比較します。提案数量が違う場合は、どちらが正しいかだけでなく、需要、在庫、リードタイム、ロットのどの入力が差を生んだかを確認します。

61〜90日：限定本番と受入判定

承認済み品目からシステム提案を運用へ移し、例外ワークフローを本番化します。週次でKPIとデータ品質をレビューし、90日目に受入試験を判定します。不合格項目は「後で対応」ではなく、是正期限、責任者、再試験方法を契約上の残件として管理します。

RFPと受入試験に入れるべき要件

機能表への○×回答だけでは、実運用の能力を比較できません。ベンダーには、自社データを用いたシナリオ試験、根拠の説明、監査ログ、障害時の復旧を示してもらいます。

非機能要件も数値ではなく業務場面で試す

応答時間、可用性、バックアップ、権限、監査、データ保持、インターフェース監視、タイムゾーン、言語表示を確認します。ただし「画面は3秒以内」だけでなく、朝の計画会議で重要品目一覧が開く、連携復旧後に重複発注を作らない、承認者不在時に代理経路へ移る、といった実務シナリオにします。

ベンダー回答で確認したいこと

• 標準機能、設定、追加開発、外部製品の境界。
• パラメータ計算の説明可能性と変更履歴。
• データ移行、クレンジング、初期棚卸の責任分担。
• ERP/WMS/MESとの連携方式、再送、重複排除、監視。
• 多言語、拠点別タイムゾーン、単位、通貨への対応。
• 本番後のSLA、問い合わせ経路、バージョンアップ影響。
• ライセンス以外の導入、連携、教育、運用、追加環境の費用。

BOIの制度を検討する場合は、Thailand BOI 2025 Investment Promotion Guideなどの公式情報を起点に、対象となるデジタル化・効率向上施策、申請時期、条件を案件ごとに確認してください。システム導入だけで優遇が受けられると約束することはできません。

ROI/TCOの試算モデル：欠品削減だけで投資判断しない

以下は市場ベンチマークや実在顧客の事例ではなく、計算方法を示すための仮想モデルです。自社の実績値に置き換えてください。

モデルの前提

• アクティブな品目×ロケーション：3,000件
• 重要品目：450件
• 欠品イベント：年間120件
• 1イベント当たりの限界利益逸失またはライン影響相当：18,000 THB
• 安定稼働後に回避可能な欠品：35%
• 緊急輸送・督促費：年間480,000 THB、そのうち回避可能30%
• 火消し管理工数：年間1,200時間、時間単価350 THB、そのうち回避可能35%
• 初期導入費：2,400,000 THB
• 年間運用費：720,000 THB

ここで18,000 THBは売上全額でも純利益でもありません。欠品に伴う限界利益逸失、ライン停止・段取り変更などの運用影響を一つの等価値に置いた仮定です。重複計上を避けるため、実際の試算では、売上影響とライン影響が同じ事象を表していないか確認します。

年間回避効果の計算

1. 欠品影響：120件 × 18,000 THB × 35% ＝ 756,000 THB/年
2. 緊急輸送・督促：480,000 THB × 30% ＝ 144,000 THB/年
3. 火消し工数：1,200時間 × 350 THB × 35% ＝ 147,000 THB/年
4. 合計年間効果：756,000＋144,000＋147,000 ＝ 1,047,000 THB/年

年間運用費を差し引いた定常年のネット効果は、1,047,000−720,000＝327,000 THB/年です。単純回収期間を「初期費用÷運用費控除後効果」で置くと、2,400,000÷327,000≒7.34年です。この条件だけなら、欠品回避効果だけで導入を正当化するには弱く、スコープ縮小、初期費用低減、より大きい損失品目への集中、他の業務効果の検証が必要という判断になります。

一方、運用費を無視して総効果だけで2.29年と見せるのは不適切です。TCOには、ライセンス、クラウド、連携監視、マスタ保守、サポート、教育、棚卸、改善会議の工数も含めます。

感度をどう見るか

欠品回避率が変わると結果は大きく動きます。ほかの前提を固定した単純感度は次の通りです。

この表では、緊急輸送の回避144,000 THBと工数削減147,000 THBを固定しています。実際には各効果が連動するため、低位・基準・高位のシナリオを別々に設定します。

試算から除外したもの

このモデルは、在庫金額の増減、廃棄・陳腐化、顧客違約、品質、安全、売上成長、税務・投資優遇、資金調達コストを含みません。運転資本は利益効果と混ぜず、平均在庫額、支払条件、資本コストで別に評価します。安全在庫を増やして欠品を減らす案は、サービス改善と運転資本増加の両方を示します。

導入で起きやすい失敗と対策

失敗1：アラート画面を完成形と考える

通知後の担当、期限、判断、実行、再発防止がなければ、担当者のメール作業が増えるだけです。受入試験に例外ケースの完了までを含めます。

失敗2：安全在庫を一律に増やす

欠品は一時的に減っても、在庫過多や陳腐化を招きます。品目重要度と原因別に対策し、サービスと在庫のトレードオフを承認します。

失敗3：在庫差異をシステム外で調整する

表計算や口頭で数字だけ合わせると、原因が消えます。差異調整には理由コード、証跡、承認、再発防止タスクを必須にします。

失敗4：リードタイムを固定値のまま放置する

平均だけでは遅延側のリスクが見えません。発注から受入可能までの実績を区間別に取り、供給者・輸送条件・品目別に見直します。

失敗5：リアルタイムという言葉だけで要件を終える

秒単位が必要なデータと、日次で十分なデータを分けます。更新間隔、最大遅延、失敗検知、復旧、古いデータの表示を受入条件にします。

失敗6：AIや自動最適化を先に入れる

入力の在庫、需要、リードタイム、結果フィードバックが不安定なら、提案の信頼を失います。まず5層ループと監査可能なルールを確立し、その後に予測や最適化の対象を広げます。

失敗7：KPIが欠品件数だけ

生産量や品目数が変われば件数の比較は歪みます。重要品目当たりの欠品率、予測リード時間、例外SLA、在庫精度、緊急費、工数、再発率を併用します。

失敗8：パイロットがデモで終わる

きれいなサンプルデータでは課題が出ません。実データ、実ユーザー、実承認、連携停止、差異、計画変更を含むシナリオで試します。

KPI設計：成果・先行・健全性を分ける

欠品防止のKPIは三群に分けると、在庫を増やして件数だけ下げる行動を防げます。

成果KPI

• 重要品目の欠品イベント率
• 欠品によるライン影響時間
• 顧客納期影響件数
• 緊急輸送・督促費
• 同一原因の再発率

先行KPI

• 欠品予測の平均先行日数
• 期限内に判断された例外の割合
• 補充提案の承認・修正・却下率
• サイクルカウント計画の完了率
• パラメータ見直し期限の遵守率

健全性KPI

• 重要品目の在庫精度
• 連携成功率と最大データ遅延
• 発注点・安全在庫の長期未見直し件数
• 平均在庫額、過剰・滞留在庫
• ユーザーによるシステム外調整件数

KPIには定義、分母、除外、集計時刻、正本を付けます。「欠品ゼロ」を絶対目標にすると在庫を過剰に持つ誘因が生まれるため、サービス、在庫、対応費のバランスで評価します。

FAQ：欠品防止システムの選定でよくある質問

欠品防止システムとは何ですか？

実在庫、将来需要、補充リードタイム、発注点や安全在庫、例外対応、事後改善をつなぎ、欠品を予測・予防・収束させる仕組みです。単なる在庫一覧やアラート画面ではなく、担当者の判断と実行記録まで含む制御ループとして設計します。

在庫管理の見える化だけで欠品は防げますか？

見える化は必要ですが十分ではありません。在庫が正確でも、需要変化、供給遅延、担当不明、判断遅れがあれば欠品します。未来在庫、補充提案、例外ワークフロー、パラメータ見直しまで接続する必要があります。

発注点管理システムはどの品目に向きますか？

反復的に消費され、需要とリードタイムが比較的安定し、独立需要として扱える品目に向きます。BOM従属需要や大きな季節変動がある品目は、MRPや予測連動と組み合わせます。

安全在庫は多いほど良いですか？

いいえ。安全在庫は供給サービスを高める一方、運転資本、保管、陳腐化の負担を増やします。重要度、需要・リードタイム変動、目標サービス、代替可否を基に設定し、実績から見直します。

リアルタイム在庫管理には何秒単位の更新が必要ですか？

一律の正解はありません。ライン払い出しは即時、購買確定納期は変更時、予測は日次でも足りる場合があります。データごとに許容遅延、失敗検知、古さの表示を決め、判断に必要な時間内で更新されることを試験します。

在庫差異の原因と対策はどのように管理しますか？

入荷、移動、払い出し、単位、廃棄、品質状態、ロット、連携などの理由コードで分類します。差異を承認して終わらず、発生工程、証跡、恒久対策、責任者、期限を記録し、重要品目の再発を追います。

WMS、ERP、MESのどれに実装すべきですか？

実在庫の実行はWMS、購買・MRP・会計はERP、生産消費や進捗はMESが正本になりやすい一方、製品構成によって異なります。一つに全機能を寄せるより、正本と連携責任、障害時の挙動を明確にすることが重要です。

90日で導入効果を判定できますか？

全社ROIの確定には短い場合がありますが、対象品目でデータ精度、予測先行時間、例外SLA、提案の説明可能性、ユーザー運用を判定するには有効です。季節性が強い場合は、90日後も追跡期間を設けます。

欠品防止システムの費用はどう比較しますか？

ライセンスだけでなく、初期設定、データ移行、連携、教育、サポート、クラウド、マスタ保守、改善工数をTCOで比較します。効果側も、限界利益・運用影響、緊急費、工数、運転資本を分け、二重計上を避けます。

ベンダー選定で最重要のデモは何ですか？

自社データを使い、在庫差異、生産計画前倒し、納入遅延、連携停止を発生させ、再計算、担当割当、承認、監査ログ、復旧まで見せてもらうことです。正常時のダッシュボードだけでは能力を判定できません。

まとめ：欠品を減らすのは画面ではなく閉じた運用ループ

欠品防止システムの選定では、機能数より、実在庫、需要と時間、補充方針、例外処理、学習と統制の5層がつながっているかを見ます。発注点、Min/Max、MRP・予測は品目特性で使い分け、RACIで判断者を定め、90日パイロットとRFP受入試験で実力を確かめます。効果は仮定を明示し、限界利益・運用影響、緊急費、工数、運転資本を分けて評価してください。

タイ・ASEAN工場で、欠品原因の整理、重要品目の選定、RFP受入条件の作成から検討したい段階でもご相談いただけます。現在のERP・WMS・MESを前提に、どこをつなぎ、どこから小さく実証するかを一緒に整理します。TOMAS TECHへのお問い合わせをご利用ください。

参考資料

• SAP: Reorder Point Planning
• SAP: Safety Stock and Buffer Simulation
• Microsoft: Safety stock fulfillment
• Microsoft: Cycle counting
• Oracle: Min-Max Planning
• Oracle: Multi-echelon Inventory Optimization 26C
• GS1 General Specifications
• Thailand BOI: A Guide to the BOI 2025