フリーダイヤル0120125308

2019年03月12日配信分
ttl_column

在庫管理システムの担当者が知らなきゃいけない業務知識 ~受注に対する在庫の引当④~

mailmaga244

画像素材: Sashkin7 / PIXTA

 

*** イノベーションの実用化までのリードタイム ***

 

1920年代の末、イギリスのアレキサンダー・フレミング博士は、抗生物質のカビであるペニシリンを発見しました。
しかし、フレミング博士がペニシリンを発見してから、医療用として実用化されるまでには10年以上の歳月を要しました。
それでもペニシリンの開発を早めたのは第二次世界大戦であったとされています。

生化学者のハワード・フローリはフレミング博士がペニシリンを発見した10年後に研究に着手しました。
第二次世界大戦中、感染症の特効薬を必要としていたイギリス政府はフローリの研究を推進しました。
そして、彼のもとには戦場から多くの負傷兵が臨床試験のために運ばれたのです。
もし、第二次世界大戦が起こらなければ、「20世紀における偉大なイノベーション」の1つとされるペニシリンの実用化は、もう20年遅れたのではないかと言われています。

実は我々が日常で利用しているコンピューターも第二次世界大戦によって、一気に開発が進んだ参考に値すべきイノベーションの一つです。
第二次世界大戦時に、アメリカ政府はコンピューターの開発に大量の人とお金を注ぎ込みました。
その後押しを受け、1947年ベル研究所でトランジスタが開発されたのです。

イノベーションの実用化には通常、長いリードタイムを必要とします。
しかし、過去の偉大なイノベーションの歴史を辿ると、イノベーションが実用化にいたるまでのリードタイムを短縮するのは、外部の危機がやってきたときだけなのです。

皆さんもすでにご存知のAI(人工知能)やビッグデータ、RPA(ロボティック・プロセス・オートメーション)等のイノベーションが、物流領域によって実用化が急加速するのは間違いないと確信しています。
「物流クライシス」が叫ばれる今がまさに、イノベーションの実用化を加速させる大きな機会(チャンス)だと言えるのです。

 

共通バナー(輸快通快)ver

 

*** 引当の編集(再引当、編集、解除) ***

 

さて、本題に移ります。
前回、前々回で在庫引当処理の5つのポイントのうち、1と2と3について解説をいたしました。
今回は、「4.引当の編集(再引当、編集、解除)」と「5.引当の範囲と優先順位」について順を追って解説させて頂きます。

 

244-1

 

在庫管理システムを設計、実装する上で難しいのは実はここからです。
基幹システム(販売管理システム)から受注データを取り込むタイミングで、在庫引当処理が実行される点については、前回解説した通りです。
また、受注数量に対して在庫が不足していた場合は欠品扱いとなる点についても既に解説済みですね。
しかし、一旦欠品扱いとなった商品がその後に入荷された場合、在庫管理システム側ではどのような対応が必要になるでしょうか。
皆さんも考えてみて下さい。

実際の運用では、入荷された商品は一度欠品扱いとなった受注に対して、直ちに出荷処理が行われることになります。
在庫管理システムでは、こうした場合の処理を「再引当」処理として実装する必要があります。

この再引当処理が無いと、一度欠品扱いになった受注については、その先の出荷処理をアナログで行う必要が生じる為、出荷実績データの手入力、在庫の調整等が発生することになります。

再引当処理については、いくつか実装パターンがありますが、今回は一般的な受注データ(出荷指示データ)を指定する方法をご紹介します。

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

下記の図をご覧ください。
これは「在庫引当管理画面」を簡単にイメージにした図です。
ベアリングカバーの欠品により、納品先の異なる3伝票が欠品扱いとなっています。その後欠品していたベアリングカバーが20個入庫登録されました。
この時点で在庫管理システムの理論在庫数量は20個になります。
在庫引当管理画面より欠品している伝票を指定して優先的に引当を行うデータに対して引当実行ボタンをクリックします。

 

244-2

 

これによって徳川工業株式会社の出荷処理を続行出来ることになりました。
再引当処理については、この方法の以外にも自動で処理を行う場合もあります。
ハンディターミナルやPC画面から入荷実績情報が登録されたタイミングで、自動的に欠品していた受注データに対して引当がされる仕組みです。
この仕組みは、手動で行う再引当処理よりも少し高度なロジックを実装する必要があります。
しかし、現場では毎回在庫引当管理画面を開いて手動で引当を行わなくて良いので便利です。
但し、納品先に対して出荷の優先順位が重要な場合等は勝手にシステムが優先順位を決めて引当してしまう為、注意が必要です。

少し古い在庫管理システムだと、当日入荷された実績データを元に、夜間バッチで再引当処理を実行し、翌日の出荷処理を行うといった仕組みがありますが、これだと在庫管理システムの都合によって1日余分にリードタイムが発生する為、お勧め出来ません。(最近はあまり見かけなくなりました)

また、在庫の引当編集、解除も行える必要があります。上図のような在庫引当管理画面上で受注データを指定して、引当を解除したり、既に引当されている受注データと欠品している受注データの優先順位を変更したりする機能です。

再引当・編集・解除の3つの機能があれば、ある程度現場で発生するイレギュラー処理にも在庫管理システムが対応出来るため、実装を検討しましょう。
但しこの3つの基本的な機能だけでは在庫管理システムで対応出来ないイレギュラーも実は存在します。
例えば、在庫引当されて出荷指示まで出力されて、いざ出荷しようとすると実際の在庫が無い場合です。
あってはならないことではありますが、実運用では十分に想定されますね。

この場合は、在庫引当された状態で理論在庫が残ったままにならないような処理が必要になります。
もう一つご紹介すると、在庫引当されて出荷指示が出力されて出荷実績まで計上したところで、突然出荷のキャンセルが納品先からきた場合です。
現場や在庫管理システム担当者からすると「もういいかがんにしてよ!」という気持ちですね。

在庫管理システム側では出荷実績データと受注データ(出荷指示データ)を削除することになりますが、そうすると引当されていた在庫が宙に浮くことになってしまいます。
その宙に浮いてしまった理論在庫の処理をどうするのか。再度別の受注データに引当てるのか、一旦有効在庫としてそのまま理論在庫に戻すのか・・・。
色々とありますが、少しずつ落ち着いて整理しながら実装を進めていきましょう。

 

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

 

さて、引当処理の最後のポイントは引当範囲と優先順位についてです。
受注データに対して全てを引当対象に出来ない場合があります。
例えば、基幹システム(販売管理システム)側で当日出荷分以外の未来の受注残データ全てが出力されるケースです。
在庫管理システム側の都合で言えば、当日出荷分、もしくは今から出荷処理を行う必要のある受注データのみを基幹システム(販売管理システム)から取込みたいところです。

しかし、基幹システム(販売管理システム)側の都合でどうしても、受注残全てが出力されて在庫管理システムに連携されるような場合は、在庫管理システム側で引当対象範囲を指定する必要があります。
この場合の指定は人が手動で行うのではなく、引当実行時に自動的に選別される必要があります。

またそれ以外にも、引当の優先順位をロジックに組み込む必要が発生します。
例えば、あるホームセンターの各店へ商品を出荷する為の出荷指示データを在庫管理システムが受信して在庫引当を行う場合を想定します。
以下の図のように花粉撃退スプレーを各店舗へ出荷するのですが、通常扱いのデータと特売扱いのデータが存在する場合は、まず特売扱いのデータから優先的に引当てる必要があります。

 

244-3

 

このように引当の対象範囲と優先順については、業種や業態、そして基幹システム(販売管理システム)側の仕様によって、在庫管理システムで求められる要件が変わってきます。
この点についても、基幹システムベンダーや各部署、現場にしっかりと事前確認をしておきましょう。

 

*** まとめ ***

 

在庫管理システムの担当者が知らなきゃいけない、受注に対する在庫の引当処理の5つのポイントについてここまで解説してきました。
多少上から目線で解説をさせて頂いた5つのポイントですが実は、全て漏れなく筆者がこれまでクライアントへ導入する時に失敗を経験したものです。

数ある失敗の経験から、在庫管理システムの導入で一番重要なのは「在庫引当処理のロジック」だと痛感しています。
今回は結果的に、かなりニッチな内容になってしまいました。
誰がこれを読むのだろうと正直不安にもなりましたが、在庫管理システムの導入で失敗を経験された方、これから在庫管理システムを導入する上で何を重点的に確認しておけば良いか悩まれている方のお役に少しでも立てれば本望です。
是非、素晴らしい在庫管理システムを導入して下さい!

 

*** 最後まで読んで頂いた方にお知らせ ***

 

私達が開発を進めている「INTER-STOCK」はただのパッケージシステムではありません。
クライアント企業、協力パートナーと一緒にこれからも常に進化を続けていくロジスティクス領域のIT化支援プロジェクトです。

お蔭様で最近は、日本を代表する有名企業から沢山のご相談を受けるプロジェクトに成長してきました。
我々のプロジェクトで実現する、今後の予定を少しだけご紹介しますね。

 

1.オーダーデータから梱包タイプを事前に決定することで輸送コストを最小限に抑える機能をクラウド上でAPI公開し、日本中の
  基幹システム、物流システムがアクセス可能に!

2.オムニチャネル時代に対応できる複数拠点(倉庫、店舗)の在庫を送料と在庫量で最適な出荷拠点から引当てし、これまでにない
  レベルでフルフィルメントを最適化!

3.国内初の強力なマルチキャリアプラットフォームを開発し、国内の運送会社と企業をITで繋ぐ!

 

弊社のINTER-STOCKを導入頂くということは、こうしたロジスティクスの明るい未来への積極的な投資の第一歩、共創パートナーと一員となることでもあります。
是非この機会にご検討下さい。

 

セミスクラッチ導入型倉庫管理システム(WMS)