受注数に対して、現状のシステム在庫数が大きければ引当ＯＫとなります。

 

• 引当ＯＫ：そのまま出荷処理
• 引当ＮＧ：受注数に対して在庫が足りない事になるので欠品処理

 

へとそれぞれ流れます。欠品リストを在庫管理システムから出力し、欠品報告、発注処理（製造品の場合は製造依頼）と流れていきます。

 

*実例で知る在庫引当処理*

下図をご覧ください。グラバー商会から空気清浄器30台の受注が入りました。

 

 

 

この時、在庫管理システムの在庫数は50台なので、引当ＯＫとなります。

 

これが在庫引当の基本ロジックです。

• 受注数＜＝在庫数なら引当ＯＫ
• 受注数＞在庫数なら引当ＮＧ

 

とてもシンプルなロジックです。そしてこの基本ロジックに対して、実際の運用に関する様々な条件を付けたしていくことになります。

 

まず必ず必要になるのが「有効在庫数」という考え方です。

 

実は上記の基本ロジックだけでシステムを設計してしまうと大きな欠陥があります。

 

通常受注データは一つの品目に対して複数の受注を受けることになります。上記の基本ロジックだけだと受注受付後の欠品が多発してしまうのです。下記の図をご覧ください。

 

 

 

1件目のグラバー商会の30台の受注は、在庫が50台あるので引当ＯＫになります。

 

この状態で、出荷が行われる前に新たに松下物産から40台の受注を受け付けると、この時も在庫がまだ50台あるので引当ＯＫになります。

 

 

結果、50台の在庫数に対して70台の受注を受け付けたことになり、いざ出荷処理をすると20台の欠品が発生してしまいます。

 

 

この問題については、有効在庫数という項目を追加することで解決出来ます。下図をご覧ください。

 

 

グラバー商会から30台の受注を受け付けたタイミングで有効在庫数が20台に変更されます。

 

出荷はまだされていないので、倉庫には在庫は50台あるのですが、受注に引当可能な有効在庫数は20台の為、2件目の松下物産の40台の受注は受付不可となるわけです。

 

※有効在庫数は引当可能数と表現する場合もあります。現場の方が分かり易い方を選んであげましょう。

 

在庫引当処理の5つのポイント

ここでは、在庫管理システムの導入で失敗しない為に必ずおさえておきたい下記5つのポイントについて順に解説したいと思います。

 

 

 

この5つのポイントについて、自社のシステムの設計が運用に合っているかを関係部門と協議し、また在庫管理システムのパッケージを導入する際は、パッケージの基本設計がどうなっているかをベンダー側に必ず質問するようにしましょう。

 

**1．引当処理をどこで行うか？**

新たに倉庫管理システムや在庫管理システムを導入する際に、在庫引当処理をどこで行うかがよく議論になります。

 

• これまで通り基幹システム（販売管理システム）側で行うのか
• 倉庫管理システム、在庫管理システム側に任せるのか

 

この点については、世の中にこうしなさいという方法論や正解が無い為、多くの方が悩まれます。
まずは、それぞれのメリットとデメリットを簡単に整理してみましょう。

 

 

 

筆者の見解としては、最近ではAPIによるシステム間のリアルタイム連携が主流になっていますので、基幹システム側と在庫管理システム側でAPI連携による在庫同期が可能であれば、在庫管理システム側で引当処理を実行するのがベストだと考えます。

※API・・・アプリケーションプログラミングインタフェース（Application Programming Interface）の略。ソフトウェア同士がデータをやり取りする際に使用するインターフェースのこと。

 

基幹システムにはロット別在庫や、ロケーション別在庫といった考え方が基本設計されていない場合が多いので、引当処理を実施しても結局在庫数だけの引当になってしまいます。

 

これだと結局、在庫管理システム側でロットやロケーションを考慮した引当処理を再度実行する必要になる為、引当処理が重複してしまいます。

 

基幹システム側で在庫管理システムと在庫同期する改修コストが余程高額でない限りは、倉庫管理システムや在庫管理システム側で引当処理を行う事を推奨いたします。

 

**2．引当の対象について**

顧客から商品の購入意思が示されると、受注処理が確定します。受注が確定すると基幹システム（販売管理システム）に受注伝票データが登録されます。

 

このとき、倉庫に保管されている在庫数が受注数より多ければ、その在庫が引当され、処理は問題なく完了します。

 

一方、在庫数が受注数より少ない場合には、対応を分ける必要があります。

 

1. 欠品扱いとして受注を取り消す
2. 未来在庫に対して引当を行い、顧客に最短納期を回答する

 

1の場合、受注データをキャンセル登録すればよいため処理は簡単です。2の場合は、在庫管理システム担当者やエンジニアにとって難しい判断となります。

 

「未来在庫」とは業態によって考え方が異なります。

 

仕入販売型のビジネスであれば発注済みの商品が未来在庫となり、製造販売型であれば生産指示済みの製品が未来在庫となります。

 

この未来在庫を引当対象にする場合、いつその商品が実在庫になるかを正確に把握することが不可欠です。

 

そのためには仕入先や製造部門からの納期回答の精度が重要であり、リードタイムを緻密に管理するマスタ設定も欠かせません。

 

 

 

在庫管理担当者やエンジニアは、どこまでを在庫引当の対象とするか を、販売部門や製造部門と十分に確認する必要があります。仕入商品や製造品であっても、確約できない不確実な在庫は、引当対象から外す判断が求められます。

未来在庫を引当対象にするということは、仕入先や製造部門からの納期回答をそのまま顧客に約束することを意味します。もし信頼性の低いまま未来在庫を引当対象に含めてしまうと、在庫管理システム全体の信頼性を損ねるリスクがあります。

 

仕入商品については、仕入先ごとのリードタイム設定 が重要です。信頼できる仕入先であれば、実際のリードタイムをそのままマスタ値として登録すれば問題ありません。しかし、納期遵守率が低い仕入先や海外輸入など不確実性の高い取引先については、実リードタイムにバッファを加えてマスタ値を設定すべきです。これにより顧客への納期回答が現実的になり、トラブルを防げます。

 

製造品については、どの段階の生産計画を引当対象とするか を明確に決めることが重要です。例えば、3ヶ月先の未確定計画を対象にするのか、1週間先の確定計画に絞るのか、あるいは実際に着手された計画のみを対象にするのか──。これらを生産部門と協議し、社内ルールとして整理する必要があります。

 

引当対象を明確にすることで、販売部門は顧客に対して納期交渉をスムーズに行えるようになります。間接的ではありますが、これは結果として売上向上にもつながる重要な取り組みなのです。

*3．引当の種類について*

基幹システム（販売管理システム）から在庫管理システムに受注データを取り込む際、在庫引当を行うにはどの在庫を優先的に充当するかというルール設定が必要です。

 

その中で最も一般的なのが、先入れ先出し（FIFO: First In, First Out）ルールです。

 

 

先入れ先出しとは、文字通り「先に倉庫に入庫された商品から先に出庫する」という考え方です。特にロット管理や消費期限管理が必要な商品では、このルールを適用することが必須となります。

 

 

必ずしもすべての商材で必要というわけではありませんが、近年は医療・医薬品・食品以外の分野でも、ロット管理や期限管理への要求が厳しくなっています。そのため、今後在庫管理システムを導入する場合には、先入れ先出しによる在庫引当機能を標準で備えておくことを強くおすすめします。

 

 

以下の図は、倉庫内における先入れ先出しのオペレーションイメージです。新しく入庫した商品は棚の奥に格納し、出庫時には棚の手前にある古い商品から順に取り出していきます。これにより、在庫の鮮度を保ち、品質劣化や廃棄リスクを防止できます。

 

 

 

続いて在庫管理システムのデータイメージで解説します。

 

 

同一商品でロットの異なる3つの在庫が保管されています。

 

 

この時のロットは倉庫に入庫された日付をYYMMDDの日付形式でロット項目にセットしています。
受注データに対して一番ロットの古い180713(2018年7月13日)に入庫された在庫が引当されることになります。

 

ここまでであれば、あまり複雑なロジックではないのですが、実際にはこのロジックにもう少し作り込みが必要になります。

 

 

例えば受注数が30であった場合です。一番古いロット180713の在庫だと20個で足りません。そうなると次に古い190203の在庫からもう10個引き当てが必要になります。

 

 

しかし、ユニットロードの面から考慮すると、先入れ先出しよりも、受注数30個をそのまま出庫できる190301のロットを出庫した
いという気持ちもあります。

 

 

先入れ先出しを優先するか、ユニットロードを優先するか。こうした優先順位決めも必要になります。

 

※ユニットロード・・・パレット、ケース等、荷姿の異なる荷物を標準的な大きさにまとめ、輸送の効率化を図ること。

 

 

このようにロットや賞味期限で先入れ先出しをする在庫引当処理は多少難解なロジック実装が必要ですが、今後は増々必要になってくる機能ですので、是非頭に入れておいてください。

 

*4．引当の編集（再引当、編集、解除）*

 

在庫管理システムを設計・実装する上で、本当に難しくなるのはここからです。基幹システム（販売管理システム）から受注データを取り込み、そのタイミングで在庫引当処理が実行されることはすでに説明しました。また、受注数量に対して在庫が不足していた場合は欠品扱いになることも解説した通りです。

 

では、一度欠品扱いとなった商品が、その後に入荷された場合はどうでしょうか。在庫管理システム側ではどのような対応が必要になるのか、ぜひ考えてみてください。

実際の運用では、新たに入荷された商品は、まず欠品扱いとなっていた受注に優先的に割り当てられ、直ちに出荷処理へと進みます。これをシステムで実現するために必要なのが「再引当処理」です。

 

もし再引当処理が実装されていなければ、一度欠品扱いとなった受注はシステム上で止まったままになり、後続の出荷処理をアナログで対応しなければなりません。結果として、出荷実績データの手入力や在庫数の調整といった余分な作業が発生してしまいます。

 

再引当処理の実装にはいくつかの方法がありますが、ここでは最も一般的な「受注データ（出荷指示データ）を指定する方法」を紹介します。

 

この方法では、欠品していた商品が入荷された時点で、欠品扱いとなっている受注データ（出荷指示データ）を伝票番号（指示番号）単位で指定し、再引当処理を手動で実行します。

 

下記の図は「在庫引当管理画面」をイメージしたものです。ベアリングカバーが欠品し、納品先の異なる3つの伝票が欠品扱いとなっています。その後、欠品していたベアリングカバーが20個入庫されました。この時点でシステム上の理論在庫数量は20個に更新されます。

 

具体的には、ハンディターミナルやPC画面から入荷実績が登録されたタイミングで、システムが自動的に欠品中の受注データへ引当を行う仕組みです。手動処理に比べて高度なロジックが必要ですが、現場担当者が毎回「在庫引当管理画面」を開いて操作する必要がなくなるため、非常に便利です。

 

ただし注意点もあります。例えば納品先ごとの出荷優先順位が重要なケースでは、システムが独自に順番を決めて引当を行ってしまう可能性があります。この場合は期待した順序で出荷できないリスクがあるため、事前に十分な検討が必要です。

 

加えて、在庫管理システムには引当の編集や解除機能も備えておくべきです。在庫引当管理画面で受注データを指定し、引当を解除したり、既に引当済みの受注と欠品中の受注の優先順位を入れ替えたりできるようにしておくと、柔軟な運用が可能になります。

 

つまり、再引当・編集・解除の3機能があれば、現場で日常的に発生する多くのイレギュラー処理に対応できると言えます。システム設計時には必ず実装を検討しましょう。

 

しかし、これら基本機能だけでは対応できないケースもあります。

 

例えば、在庫を引当済みで出荷指示書まで発行したのに、実際に出荷しようとすると棚に商品が存在しないといった事態です。本来あってはならないことですが、実運用では十分に起こり得ます。

 

この場合は、引当済みの在庫がシステム上に残ったままにならないよう、在庫調整の仕組みを用意する必要があります。

 

もう一つのケースは、出荷実績まで計上した後に顧客から出荷キャンセルの連絡が入る場合です。現場担当者からすると「もう勘弁してほしい…」という状況ですが、システム上では受注データと出荷実績を削除する必要があり、その結果引当されていた在庫が宙に浮いてしまいます。

 

この宙に浮いた在庫をどう処理するかも設計ポイントです。別の受注データに再引当するのか、一旦有効在庫として戻すのか、運用方針に沿ったルールを決めておかなければなりません。

 

在庫引当周りの処理は複雑に見えますが、ポイントごとに整理して対応すれば着実に実装できます。焦らず一つずつルール化し、システムに落とし込んでいくことが大切です。

*5．引当の範囲と優先順位*

引当処理の最後のポイントは、引当範囲と優先順位の設定です。

 

受注データであっても、すべてを引当対象にできるとは限りません。例えば、基幹システム（販売管理システム）から当日出荷分以外の未来の受注残データまで一括で出力されるケースがあります。

 

在庫管理システムの立場から見れば、本来は「当日出荷分」や「今すぐ出荷処理が必要な受注データ」だけを取り込みたいところです。
しかし、基幹システム側の仕様上、どうしても受注残すべてが連携される場合もあります。その場合は、在庫管理システム側で引当対象範囲を自動的に絞り込む仕組みが必要です。

 

ここで重要なのは、担当者が手動で選ぶのではなく、引当実行時にシステムが条件に基づいて自動で選別することです。
さらに、引当ロジックには優先順位の考え方も組み込む必要があります。

 

たとえば、あるホームセンターの各店舗に商品を出荷するケースを考えてみましょう。倉庫から「花粉撃退スプレー」を各店舗に出荷する際、受注データには「通常扱い」と「特売扱い」の2種類が含まれているとします。この場合、特売扱いの受注データを優先して引当てるルールを組み込まなければなりません。

 

このように、引当範囲の自動指定と優先順位付けを明確にしておくことで、在庫引当処理は現場の実務に即した形で正しく機能します。

この点についても、基幹システムベンダーや各部署、現場にしっかりと事前確認をしておきましょう。

まとめ

在庫の引当処理は、単純な様でいて実は非常に奥が深く、企業によってその方法は様々なのでロジックは難解になります。

 

 

自社の在庫引当処理のロジック構築に悩んでいる方、または今後在庫管理システムをパッケージベンダーから購入される際に失敗をして頂きたくないので、少々マニアックな内容でしたが解説をしました。

 

 

今回の内容について分かりにくかった、自社の引当処理について相談したいという方がいらっしゃれば、在庫お悩み相談までお気軽にお問合せ下さい。

 

筆者が責任と誠意を持って回答させて頂きます。

 

【補足】高度化が進む在庫引当処理

近年、在庫引当処理にもより高度なニーズが求められるようになってきました。

たとえば、在庫が複数のロケーションやフリーロケーションに分散して保管されている場合です。このような状況では、ピッキング作業の効率を高めるために、最も作業動線が短く効率的なロケーションから在庫を引当てる仕組みが必要になります。これは、ピッキング効率を最優先にした在庫引当処理の考え方です。

以下の図をご覧ください。商品Aと商品Bを同時にピッキングし、出荷場まで運ぶケースを想定しています。

ピッキングのスタート地点から出荷場までは一直線に配置されています。この条件下で最も効率的な作業動線は、①のゾーンにある商品Aを先にピッキングするルートです。

したがって、在庫管理システムのロジックとしては、①のゾーンにある商品Aを優先的に引当てる仕組みを実装することになります。こうした「動線最適化型の在庫引当」は、現場の作業効率を大きく改善する効果があります。

このほかにも、今後の在庫引当処理にはさまざまなニーズが増えていくと考えられます。例えば…

• 出荷期限や配送便ごとの締め時間を考慮した引当

• 顧客ランクや取引条件に応じた優先順位付け

• 倉庫内の混雑状況を踏まえたリアルタイムなロケーション選択

 

在庫管理システムには、こうした多様な要件に柔軟に対応できる設計が求められています。

その他、今後増えていく在庫引当処理のニーズについて少しだけご紹介いたします。