« 在庫引当から在庫推移へ(前編) | トップページ | 関数従属性は多重度に先行して認識される »

2006.08.19

在庫引当から在庫推移へ(後編)

 在庫の受払をともなう取引にはさまざまなものがある。販売業では、仕入入荷にともなう入庫や売上出荷にともなう出庫が代表的だが、これらに棚卸や倉庫間移動等の一般在庫取引にともなう受払が加わる。以上に加えて製造業では、工程への払出出庫や、工程からの完成入庫といった取引も加わる。

 筆者が提唱する「在庫推移監視方式」は、これらの多彩な取引のうち、売上出荷、仕入入荷、製造といった「将来に受払を起こすことがわかっている取引」を「受払予定」として様式化し、それぞれの品目の将来の在庫推移を眺められるようにするしくみである。このしくみにもとづいて、在庫管理者は在庫の余剰や不足に、MRP等の従来手法よりも効果的に対処できるようになる。

 言うまでもなく、「在庫推移監視方式」はコンピュータ化されたデータベースの利用を前提とする現代的な手法だ。ただし、コンピュータを使えばそのようなしくみが可能であろうことは、誰にでも予想がつく。肝心なのは、それを実現するためにどんなデータベース構造やアプリケーション構造や業務体制が必要なのかまでを盛り込んだ具体的なモデルを示すことだ。それが伴わないのなら、どんなに気の利いたアイデアも絵に描いた餅にすぎない。「科学技術を用いれば人類は火星に降り立つことができる」と語るだけでは有用なアイデアといえないのと同じだ。

Zaikosuiidb 近日公開予定の「CONCEPTWARE/販売管理」から、「在庫推移監視方式」に関わるモデルを紹介しよう。上述のように、販売管理システムで問題になる「将来の受払を引き起こす取引」は出荷予定と入荷予定なので、データモデルはこのようになる。「受払予定」がそれらのスーパータイプとして置かれている点に注意してほしい。

Zaikosuiiui このようなデータベースを用いて、入出力フォーム上で各商品毎に現在庫を起点として将来の受払予定にもとづく在庫推移を照会できるようにする。商品毎にオンデマンドで在庫推移を眺められるだけでなく、商品群などのまとまりに対して、欠品や余剰といった「在庫推移の異状」をコンピュータに検出させて、異状の生じている商品だけを一覧させるしくみも用意する。

 このような道具立てを用いて、どのような業務体制をとるべきかもはずせない問題だ。「在庫推移監視方式」では、商品群などのまとまり毎に「在庫推移を健全に保つための管理責任者」を置く。従来の「発注担当者」と似た立場ではあるが、欠品を防ぐための発注を実施するだけでなく、死蔵品を処分するための販売促進活動も行う点が異なる。彼らは、従来の発注担当のように「いかに安く仕入れたか」ではなく「いかに死蔵在庫を抑えつつスループットを送り出したか」で実績評価される。

 この方式の仕様上の利点として、システムの複雑さが「引当方式」とほとんど変わらない点を挙げられる。いくら気が利いているしくみでも、仕様が複雑すぎるのでは開発・保守にコストがかかりすぎる(そういう意味で、MRPはコストのわりに効果の小さい手法だ)。

 具体的には、上述した「受払予定」が、それぞれの取引の変化にしたがって自動的に変化し、また取引が実際に起きたときに削除されるようになっていればよい。引当方式では、引当対象期間にある出荷予定を集計して、その合計を在庫テーブルに記録するというやり方をとる。しかし、「在庫推移監視方式」では、引当は行わない。ひたすら「受払予定」をそれぞれの取引の状態に合わせてアップデートするだけだ。それらにもとづいて在庫推移がどのように変化して、どんな異状が予想されるかについてはあえてデータベース上には記録されない。また、そのような異状に対してどのようなアクションをとるべきかも不問にしている(MRPで言う「勧告オーダ」などは作らない)。

 こうしたうえで、特定の商品についてたまたま興味があれば、現在庫数量から受払予定数量を加減させた在庫推移を眺めてもらえばよい。日常的には、自分が担当する商品群に対してコンピュータで在庫推移の異状を検出させて眺めることのほうが多いだろう。検出された異状にどのように対処するかについては、人間系に悩んでもらう。このようにコンピュータと人間のそれぞれの得意分野にプロセスを分散することで、システム全体の複雑さを抑えられる。さらに詳細については、今後に公開される「CONCEPTWARE/販売管理」や、「CONCEPTWARE/生産管理」をダウンロードして眺めてほしい。

|

« 在庫引当から在庫推移へ(前編) | トップページ | 関数従属性は多重度に先行して認識される »

コメント

渡辺さんの提唱されている「在庫推移監視方式」というのは、ATP(Available to Promise)の応用だと思うんですよね。MRPⅡにおけるATPは、最終製品(end item)についてのみ需給推移を見て、販売・生産計画を立てるわけですが、渡辺さんの提案方式は、それを工程の各レベルで独立に実施しようという点がミソだと思います。

私はたいていのクライアントに対して、「未来在庫」とか「生産座席予約」いう言い方でATPの適用を推奨しているのですが、ほとんど採用されたことがありません。いったい何故なんでしょうかね。皆さん、現実に目の前に存在する在庫しか関心を持てないのでしょうか。よくわからんことであります。

佐藤知一@横浜

投稿: 佐藤知一 | 2006.08.23 22:42

佐藤さん

ユーザが目の前の在庫にこだわる傾向が強い理由として、発注においても客先からの注文においても「なるべく早く。できれば今すぐ欲しい」という調子の要求がほとんどだからではないでしょうか。

未来在庫が見えるようになれば「X週後に200個欲しいんですが」という余裕をもった発注ができるようになります。また、受注においても「なるべく早く100個ですか。60個は今すぐ出せますが、残りについてはX週後頃に出荷できます。それでかまわないようであればお受けしますがいかがでしょう」と交渉できるようになります。

そういう経験がないのであれば、将来の在庫推移を監視できる体制の効果もなかなかわかってもらえないかもしれません。

投稿: わたなべ | 2006.08.24 20:04

はじめまして。
販売管理システムを構築しているプログラマーです。

在庫について大変勉強になりました。
販売管理の知識は結構マイナーな分野って感じですね。
まだまだ勉強が足りません…

投稿: m.y | 2006.11.14 14:24

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 在庫引当から在庫推移へ(後編):

« 在庫引当から在庫推移へ(前編) | トップページ | 関数従属性は多重度に先行して認識される »