タイトル内のページ 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

        在庫引当は　物流システムのキーです

在庫のリアルタイム引当は　物流システムとして　最低限の機能です。

　 バッチ処理での在庫予想と在庫引当

　今後の在庫予想をし、発注や生産　受注可能数を把握するために　在庫引当処理が行われます。

　システムによっては、バッチ処理で計算上の予想在庫を求め、リアルに在庫引当を行わない例が

　ありますが、これは　過去に　コンピューターの能力や資源の制限からやむを得ず採られた苦肉の

　策 ですが、完全に時代遅れなシステムです。受注、発注、出荷等々のデータが　　リアルタイムに

　ランダムに 飛込んでくる現在　その処理をバッチで行っていては話になりません。

在庫引当の問題点

　在庫引当は　累積出荷予定と累積入荷予定による在庫予想です。

　本当の問題は　将来のある時点で　そのアイテムが出荷可能かどうかです。

　例えば　未引当在庫　２５０　明後日出荷希望の受注が　３００入ってくれば　２５０を引当して不足　５０

　（又は　全量未引当となります。）しかし　既に発注済の商品が　明日　５００　入荷予定だとしたら、

　これが　引当不能の為に出荷出来ないのは　バカバカしい事です。

　少なくとも　入荷予定分は表示されて　確認出来るシステムが必要です。

引当だけで十分ですか？

　さきほどの事例で　未引当在庫が　２５０　としました。ところが　その出荷予定日は　2週間も先だった

　とし、この商品は毎週　５００づつ入荷しているとします。これも　在庫引当そのものがおかしいのです。

　では　明日の入出庫予定数だけで　在庫引当すれば　ＯＫでしょうか？

それでは　既に持っている入出荷予定情報を全く活用していません ！！

　受注（出荷）予定データは　出荷予定日の順番に入ってくる訳では有りません。

　（得意先ごとに　発注のリードタイムや形態が違います）

　引当処理後に　割込みの出庫や生産が入った場合、将来の日付ごとの引当後在庫数

　を把握していなければ正確な発注、生産計画や　正確な受注は出来ません。

　まして　今出荷出来ない商品が　何日なら出荷出来るかという答えは　全く出せません。

在庫バランスの必要性

　多くの流通業システムでは　受注可能数を把握するために　引当処理をおこないます。

　しかし　それだけでは　累積受注と累積入荷予定の比較だけで将来のある時点を捉えた在庫推移は

　判定できません。

　正確な発注や生産計画には　時系列を含む　在庫バランス表が必要です。

在庫バランスの考え方

　将来のある時点での在庫は　２次元の表で考えられます。

　横軸に時間（日付）を取り、縦軸に入荷予想の各項目や出荷予想各項目とその結果として計算され

　た在庫予想値を取ります。その各フィールドに　リアルタイムで受注データや発注データ（生産予定

　データ）の増減値を加算し　在庫予想値を計算します。

在庫バランスデータの持ち方のイメージ

　イメージとしては　アイテム単位で１枚づつ存在するＥｘｃｅｌ　のシート　です。

　シート上の各フィールドに対し　　１トランザクションが発生する度に、データを加減し　

　計算結果として時間軸に対する在庫予想数が　一斉に書き換えられます。

効果

　受注（出荷）予定データは　時系列に出荷の順番で入ってくる訳では有りません。

　後から　割込みの出庫や生産が入った場合、この構造を持っていれば、特定時点毎の在庫予定

　データが捉えられ、リアルに発注や生産計画にリンク出来ます。

元来　在庫バランスの考え方は　繊維産業において先物取引をする場合の指標でした。

数ヶ月先の先物を売買する場合、単純に受注順に在庫引当したのでは　まったく用をなしません。

メーカー系のシステムでは　類似の考え方がありますが、流通系では　取引が

比較的短期レンジな為　ほとんど考慮されていません。

しかし　在庫総量の圧縮や　ＳＣＭ等　在庫スパンを広く捉えるためには　「在庫バランス」の

考え方が重要です。

総バラ　システムの弱み  

原始的な物流システムでは　在庫データを　「総バラ」で持っています。

　　古い在庫管理システムの多くが、在庫数を　すべてバラ（ピース）の数に換算した合計値で保持しています。

　　この在庫データの持ち方を　「総バラ」と通称しています。

　　クライアントの業種にもよりますが、多くの業態では　総バラ　は　致命的な欠陥を持っています。

　　現実の在庫は　段ボールケースに入った物（ケース在庫）からスタートして　その中の小包装（いわゆる　

  　子箱やボール）　に分解された状態（ボール在庫）、更には　最小単位に分離された　いわゆる　バラ

  　（ピース在庫）状態と　何通りかの形態で保管され　それぞれの状態で受注、出荷されて行きます。

　　しかるに　総バラ　で　在庫をデータを保持しているのでは　各状態での在庫数は

　　根本的に把握不可能です。

　　段ボール箱の入数を掛け算したり、ボール入数で掛け算したりして　計算上の換算数値を捉えることは

　　可能に見えますが、しょせんは　見かけ上の換算値だけで　それぞれの在庫実態とは　まったく関係

  　ありません。

　　少なくとも　「在庫管理」　を　目的にするのであれば、総バラ換算　などという　石器時代なみのシステムは

　　恥ずかしい限りです。

　　ある物流管理システムが　総バラだけで　在庫数データを保持しているとするならば、

　　そのシステムの実力は　調べてみるまでも無いと思います。

発注単位

　　多くの小売業などでは　自社独自の　「発注単位」でデータを作成しています。

　　この　「発注単位」は　受注側の単位系と　一致しているとは　限りません。

　　受注データを処理するためには　顧客ごとの　「発注単位」を　自社の物流管理単位系に変換すべきです。

　　それが出来ないと　物流現場は　顧客ごとの単位系の違いに振り回わされてしまいます。

　　在庫管理上　ケース在庫、ボール在庫、ピース在庫を　分けて管理する必要が有るのと同じく

　　商流段階では　個客ごとの　発注単位を　システムが自動認識しないと　使い物になりません。