在庫管理、

128 在庫問題は何も解決していないのだ

06:物流システム

流通システム/物流システム徒然記

このグラフは経済産業省の東日本大震災から垣間見える我が国と世界の通商・経済関係なる堅い経済白書の「我が国の自動車産業と電気機械産業等との在庫率の比較」の1960年度からの在庫率の推移です。
自動車産業と電気機械産業のグラフなので、あくまでも参考として下さい。

我が国の自動車産業と電気機械産業等との在庫率の比較
業態別/事業所数/就業者数 年間商品販売額及び売場面積の対前回増加率


公式出元サイト:『 第4-2-1-13 図 我が国の自動車産業と電気機械産業等との在庫率の比較(1960 年度末以降: 時系列)』
図の文字は小さいので、実際のホームページでご確認下さい。エクセルファイルもダウンロード出来ます。

1990年度頃までに在庫率は劇的に下がり続けています。これはコンピュータの導入による在庫調整が大きく影響しているものと思われます。
しかし、その後大きな変化は全く見られません。

確か、2000年頃にSCMは大ブームとなり、そこそこの企業はSCMシステムやSAPを代表するERPシステムを導入し始めます。
それも、物凄いシステム開発費を投入してです。


むしろ2008年のリーマンショック後の2009年度は、在庫率の若干なる上昇の気配さえ漂わせています。
残念ながら2009年の今現在、2000年の頃のようにSCMは話題にならなくなりました。

その理由は「 既にSCMは定着したからなのか? 」
いいえ、話題性がなくなっただけで多くの企業は殆ど何も変わっていないが実情のようです。

127 在庫管理の失敗で会社が吸収

06:物流システム ピックアップ

流通システム/物流システム徒然記

コンパック社は1982年に設立されたパソコンメーカーです。
IBM PC互換機として低価格戦略で瞬く間にトップ企業に躍り出ました。

1997年ノンストップコンピュータの代名詞タンデム社を買収し、破竹の勢いのコンパック社でしたが、良いことは長く続きません。

翌年の1998年には業績不振にあえぎ出します。

在庫管理の重要性


理由は何と在庫管理の失敗です。
大量生産でパソコンの価格を下げるのは良いのですが、パソコンの需要数と生産量の判断ミスをおこします。

早い話作り過ぎです。
生産した製品が工場の敷地内に積まれ、流通在庫を3ヶ月以上抱える羽目になります。


どこが問題なのか説明します。

例えば大型家電量販店クーペンギン電気に、コンパックパソコンが10台置かれていたとします。

この製品は消費者が購入して、お店は「有難うございました」となります。
そこで初めて1台さばける訳です。
商品在庫が少なくなって初めて 量販店クーペンギン電気はメーカーにオーダーします。

しかし、この製品が3ヶ月以上の在庫を抱えていることは、メーカーにとって3ヶ月以上その製品の現金を回収できないことを意味します。

製品はアメリカの工場、物流倉庫、流通倉庫のいたる場所で保管されていたでしょう。
空輸を含む運搬費/倉庫保管費/梱包費など全てを考えると、製品を供給するための物流コストは想像以上にかかります。


まだ問題はあります。
製品を作るための各部品メーカーに、「 今はお金が無いから、お金は製品が売れるまで待ってくれ! 」と言えません。
当然、在庫を現金に回収する前に部品メーカーに部品代を支払う必要が出るでしょう。

従業員の給料も待ったなしです。(実際は、かなりの従業員が解雇されます)
儲かっても儲からなくても、その他沢山の必要経費は発生します。


おまけにパソコン技術は日進月歩ゆえ 直ぐに製品は陳腐化します。
もし他社が新商品を出せば、ますます在庫製品の売れ行きは鈍るでしょう。


そんな訳で、間もなくコンパック社はヒューレット・パッカード社に吸収合併されるのでした。
いかに在庫調整って重要か分かる内容です。


(注)
2011年8月、米Hewlett-Packard(HP)は、今後 タブレット、スマートフォンからの撤退を決めた。
更に消費者向けパソコン事業からの撤退の検討もしている。
パソコン事業は同社の基幹事業の一つだったが、実現すれば大きな方針転換となる。

126 標準偏差と正規分布

06:物流システム

流通システム/物流システム徒然記

実際に定量発注方式を前提として製品マスタにデータを登録します。

いきなり定量発注方式と言っても意味が分からないかもしれませんが、在庫管理の方法に定量発注点方式と定期発注点方式があります。

それぞれには長所と短所がありますが、ひとまず定量発注方式で進めます。
定量発注方式とは あらかじめ決めておいた一定量(発注点)より在庫が減ったら製品を補充する方式です。

定量発注方式


まず、注文から実際に製品が手元に届くまでの日数(リードタイム)を製品毎に調べます。
発注点や安全在庫は難解なので、ひとまず今回は内容に触れません。

「 安全在庫ってどういう意味?」と、いろいろ意味不明な文面が出てきますが少々お待ち下さい。この話を突き進めると、標準偏差/正規分布なる言葉が出てきますが、難しい話は一切触れません。

ともあれ、大雑把に理解するために簡単明瞭に記載します。

(1) 製品を注文して手に入るまでの日数を10日とします。これを調達期間(リードタイム)と呼びます。

(2) 調達するまでの10日間にも在庫は減ります。

(3) 在庫が無くならないように安全な在庫数を考慮します。

(4) これらを考慮した上での発注すべき点(発注点)を決めます。

これを取扱い製品毎に数値を決めます。

但し、在庫コストが気にならない製品であれば,面倒な発注点を計算する必要さえないでしょう。
常にこの数字を把握します。

最初は大よその数字でOKです。
大よその数字・・・当ブログの基本テーマとするSCMと大きく矛盾しますが、最初の第一歩はこんなもんです。

あとは勘と経験と勇気で基準発注数/発注点/安全在庫数を自分自身で設定します。
最初は大よその数値=安全在庫を少し多めに見積もった数値を少しずつ安全在庫を適正な数量に近づけて行きましょう。

定量発注方式

最初のイラストは規則正しく在庫が減っているイメージですが、実際は規則正しく在庫が減ることなんて有り得ないのでイラストを少し変更しました。

詳細は別途!

125 データは色々な角度から見ろ

06:物流システム

不況の時代でも、絶好調の企業はあります。
例えばアパレルメーカー、海外で製造した原価100円の製品を日本で何倍にも価格を上げて販売する戦略。
それでも日本では低価格な値段だから、当然売れる。
しかし、国内アパレルメーカーにしてみればたまったもんじゃない。売れなければ生き残れない。

ソフトウェア業界も同じこと。中国、インドに開発を依頼すれば、開発費は半分どころか3分の1で済んでしまう。
1ヶ月100万円かかる技術者が、30万円程度で済むなら開発拠点は当然シフトする。
そうなると日本の開発技術者(主にプログラミング技術者)は溢れてしまう。

他の業種も似たようなもの、世界がグローバル化すれば安いところで生産してそれを日本で販売する。
グローバル化すればするほど、国内産業は苦しみ仕事にありつけない人が増える。



流通システム/物流システム徒然記

前回に説明したように、実際の在庫管理ソフトを例にとって説明します。
どうせ例にするなら数千万円もするような本格的な在庫管理ソフトを参考にします。
今までの項目になかったロットや保管場所(ロケーション)の項目を加えて話を進めます。


(1) 在庫マスタ(製品単位)

在庫マスタ(製品単位)


これは今まで登場した在庫データを製品単位の角度で表示したものです。

データはいろいろな角度で表示可能です。
どんなものがあるのか、代表的なものを取り上げてみます。

(2) 在庫マスタ(ロケーション別製品別)
(3) 在庫マスタ(ロケーション別)
(4) 在庫マスタ(ロット別)
(5) 在庫マスタ(ロット別ロケーション別)

これらは、どれも同じデータを単に見る角度を変えただけです。
説明の都合上ややこしくなるので、引当てが一切ない状態としています。


在庫マスタ(ロケーション別製品別)



在庫マスタ(ロケーション別)



在庫マスタ(ロット別)



在庫マスタ(ロット別ロケーション別)



このようにデータさえ蓄積されれば、色々な角度に照会が可能です。これがコンピュータを導入する最大の利点の一つです。
ちょっと、それぞれデータの特徴を眺めて下さい。

コンピュータでデータ化しなければ、とてもこんな芸当は出来ません。更にグラフ化すれば未来予測さえ出来てしまいます。
  ・
  ・
  ・
しかし、これまで製品番号CV-NX30とCV-DY22の2種類しか登場していません。
現実世界であれば2種類ってことは有り得ません。

124 トランザクションデータ

06:物流システム

連休続きで休みが多いな~って気がします。
雇われ側にとって嬉しいことですが、雇う側にとっては同じ賃金で生産力が低下するので かなり辛いです。
仕事のあるビジネスマンは、不況は他人事に感じてしまうかもしれませんが、職を失っている人にとって 、この不況は本当に深刻です。本当に仕事は激減してます。



流通システム/物流システム徒然記

前回はトランザクションなる言葉を登場させ、トランザクションとは一連の業務処理における取引データだと書きました。
当然、出荷だけではなく入荷も発生します。


と言う訳で、ちょっと入荷と出荷のトランザクションを製品の入荷日順に並べてみました。
分かり易くするため、入荷はプラス、出荷はマイナスにしています。

トランザクションデータ


ここまで数回触れてきた入出荷をトランザクションデータとして表すならこんな感じになるでしょうかね。
時系列で追う場合は分かり易いですね。
実際は分割入出荷も考えられえるし、倉庫間移動や倉庫内移動も発生します。当然それらもトランザクションデータとして発生します。

この後、WMS(Warehouse Management System =在庫管理システム)にも触れようかと思うので、英文の項目名も参考に加えました。(但し、この英文名はソフトによってまちまちです)
こうしたデータをコンピュータに蓄積しておけば、入荷日別、製品別、数量の大きい順や小さい順など自由に並び替えが出来るのでとても便利です。



入荷データ



出荷データ


前回までは出荷情報だけ載せていましたが、入荷情報も同じです。
入荷情報も出荷情報も最低限の項目しか載せていません。
実際のシステムデータは沢山の項目が付加されています。参考までに入荷データ出荷データを載せます。
これもあくまでも参考です。実務の場合、もっとデータ項目数は多いのが普通です。


さて、在庫データはどうなっているかと言えば・・・。

在庫データ


このデータ値は前回の出荷工程終了後の在庫状況です。
ピック数(picked)って項目を1つ増やしています。
実際の在庫データは、保管場所(Location)、ロット(Lot)情報なども加わります。
これらのデータが随時蓄積されることで、製品ごと、保管場所ごと、ロットごとに分析表示が出来る訳です。

こんな感じの説明は、恐らく在庫管理の書籍には触れられていないでしょう。
今、手元に数冊の在庫管理、商品管理、物流管理・・・なんて本がありますが、こんな感じでデータ項目まで触れてある本は一冊もありません。

このブログは貴重なブログなのかもしれませんよ・・・。

この際だから海外発の数千万円の在庫管理ソフトを意識しながら説明しましょう。
恐らく維持費を含めれば億単位のソフトになるでしょう。大は小を兼ねます。要らない知識は切り捨てれば良いだけです。

本当は SAP や Oracle など本格的 ERPソフト(注) と巷で売られている比較的安価な業務パッケージソフトなどを一同に集めて比較検討すれば良いのですが、手間隙がかかりすぎてとても出来ません。
一般的な在庫管理システム=WMS(Warehouse Management System)を例に進めます。

本当に詳細な在庫管理システムを知りたい人は、お尋ね下さい。


(注)
経験的に外資系企業の多くは、本社と日本支店をSAP等のERPソフトで結んで商品管理を行っているケースが多く感じられます。
外資系会社の日本国内物流システムに関与すると、かなりの確立でSAP等のERPシステムが登場します。

国内の中小企業なら、比較的低価格な業務パッケージソフトを取り入れている企業を良く見かけます。
有名なところで、オービック、ピーシーエー等に代表される在庫/販売管理ソフトなどですね。

これらのソフトからデータを抽出して企業間のEDIとしてデータ連携します。ソフトによって希望に沿ったデータが抽出出来ない場合もあって、企業間ソフトの相性は重要です。

超有名中堅企業であっても意外に低価格なパッケージソフトを利用していることはざらです。
「 何でこんな有名な会社が○○○ソフト使ってんの? 」 と思うことがあります。
在庫管理や物流システムは企業にとって非常に重要な位置づけになってはいますが、やはりまだなのかもしれません。

しかし、パッケージソフトを導入する場合、自社業務をそれに合わす必要もあって、100%満足している会社は私の知る限りいません。仕方がないことですが。

これに反して大企業になると、大抵の場合は自社開発の在庫管理システムです。開発費用も維持費用も非常に高額です。

123 さらに入出荷作業を繰り返す

06:物流システム

流通システム/物流システム徒然記

前回の内容をさらに繰り返します。
前回までは1製品、1出荷先だったので、とても単純明快でした。
しかし、現実世界で1製品、1出荷先ってことは、まずありません。

製品と出荷先を少々増やしてみます。
手順は前回と同じです。


在庫管理その1

(1) 売上げ好調、麒麟印マホービン社からインターネットで入荷データを受信しました。(2009年10月16日とします)

まもなく製品が到着します。

在庫管理その2

(2) 倉庫に製品が搬入されて来ました。
先ほどの受信データと実数量が合っているかチェックします。数量確認後は検品チェックを行います。
今回の製品の外箱に大きなへこみが見つかりました。

上の表、入荷日2009/10/16の2ラインが本日の該当データです。
ダメージ品はひとまず一時保管エリアに置き、残りの正常品を入荷計上します。

在庫マスタも載せます。前回記載の数値を含めた、今現在の在庫です。

在庫管理その3

(3) 本日も入荷と平行してヤマト電気さんと他3社から 麒麟印社へ注文が入ります。

注文を受けた麒麟印社は、クー倉庫株式会社に上記の出荷指示データを送信します。
「 この製品を指定先にXX個配達しておくれ 」のデータです。今回は出荷先量販店を4つにしました。

在庫管理その4

(4) クーペンギン倉庫はデータを受信後、在庫管理システムから自動引き当てを行います。

今回 トランザクションなるデータを登場させます。
トランザクションとは、一連の業務処理における取引データを意味します。
ちょっと難しい言葉ですね。

銀行や証券会社のオンラインで発生する取引データもトランザクションデータと呼びます。
例えば、あなたが銀行でお金を引き出した場合も その時点の取引データが発生します。
それがトランザクションデータです。
まあ、ピンと来ないかもしれませんが・・・システム開発に関係ない人は知る必要はありません。

当システムの、出荷トランザクションデータは全てマイナス値で1件づつデータが作られることとします。
と、書いた理由は、システムで色々な方法があるからです。

例によって先入れ先出しルールで古い入荷順から引き当てします。
これらは全てコンピュータで自動処理されます。
引当て直後の在庫マスタも載せます。全在庫数量を確認する場合は在庫マスタの方が把握し易いです。

(5) 前回同様に出荷指示書(ピッキングリスト)や必要書類をプリントします。
現場の担当者がピッキングリストを持って倉庫内で製品をかき集めます。



(6) かき集めた製品は、梱包や内容検品など一連の出荷工程を行います。
今回は出荷先が4箇所に分かれています。
出荷先に配送する仕組みはトラック物流会社に任せます。単純にヤマトさんや佐川さんを思い浮かべればOKです。


在庫管理その5

(7) トラックが荷物を載せて出発すれば、ひとまず出荷作業は完了です。ここで在庫を更新します。

在庫マスタも参考に載せます。
前回、前々回の説明と今回の説明で、流れが分かってきましたか?
まだまだ単純ですが、たった2製品/4出荷先だけでも、在庫管理が複雑になりそうな予感がしてきました。


それでは入荷製品を30製品/40出荷先に増やすとどうなるでしょう。
コンピュータシステムがなかったらパニック間違いなしです。
・・・その前に、今までの表の説明をします。

122 もう一度、在庫の流れを見てみよう

06:物流システム

今回の在庫管理の説明は、学校の先生の説明みたいですが、実際システムを作って、貨物を動かさなければ役に立ちません。
理屈と現実の世界は全然違う泥臭い世界ですから・・・。



流通システム/物流システム徒然記

少しくどいかもしれませんが、前回と同じことを繰り返します。


在庫管理その1

(1) 麒麟印マホービン社は売上げ好調!
麒麟印マホービン社からインターネットで入荷データを受信しました。
本日(2009年10月13日とします)、120個の入荷予定です。
貨物はまもなくトラック便で到着します。


在庫管理その2

(2) 倉庫に製品が搬入されて来ました。
先ほどの受信データと実数量が合っているかチェックします。検品チェックも行います。
明細3行目の赤文字行が本日(2009/10/13)のデータ分です。
前回の説明した入庫データもあります。前回のブログの値を参照して下さい。

入荷の日々の取引表とは別に在庫マスタを参考に記載します。
下の紫ラインの表が在庫マスタになります。上の同じ製品3行を単純に合計しただけです。

在庫管理その3

(3) 時を同じにして、ヤマト電気が麒麟印マホービン社に180個の注文を入れます。
注文を受けた麒麟印マホービン社は、クーペンギン物流倉庫に対してヤマト電気の180個の出荷を依頼します。
麒麟印マホービン社は、決められた書式で出荷データを作成し、クー物流倉庫にインターネットでデータを送信します。

在庫管理その4

(4) クー倉庫株式会社はデータを受信後、在庫管理システムから自動引き当てを行います。
前回同様、先入れ先出しルールで古い入荷順から引き当てします。
引き当て数を合計してみて下さい。
ちゃんと全部で180個引き当てしてますね。

先ほどと同じく、一つにまとめた在庫マスタも参考に載せます。

(5) 前回同様に出荷指示書(ピッキングリスト)や必要書類をプリントします。



(6) 梱包や内容検品など一連の出荷工程を行いトラック業者に製品を渡します。



在庫管理その5

(7) トラックが出発すれば、ひとまず出荷作業は完了です。ここで在庫を更新します。
ほら、出荷した180個が減っています。

一つにまとめた在庫マスタも参考に載せます。この在庫マスタは次回からの説明に生きてきます。


まだ一つの製品を一つの出荷先に送るだけなので、非常に簡単ですね。
徐々に実レベルに近い内容にします。

121 在庫管理シュミレーション

06:物流システム

流通システム/物流システム徒然記

ちょっと一風変わった感じで進めます。

クーペンギン倉庫株式会社は、国内大手物流倉庫会社です。
色々なメーカーの製品を倉庫内で管理していますが、長年に渡って麒麟印マホービン株式会社とも倉庫契約しています。


在庫管理その1

(1) メーカーである麒麟印マホービン社の神奈川工場からインターネットで入荷データを受信しました。
本日(2009年10月05日とします)、130個の入荷予定です。

企業の場合は電子データ(EDI)のやり取りが殆どですが、昔ながらのファクスや電子メールにエクセル添付でも構いません。

貨物は、まもなくトラック便で到着します。


在庫管理その2

(2) 製品到着後、倉庫に搬入します。
先ほどの受信データと実数量が合っているかチェックし、入庫検品チェックを行います。

明細2行目の赤文字行が本日(2009/10/05)の在庫です。過去の入庫(2009/09/20)したデータもあります。


在庫管理その3

(3) 翌日、大手家電量販店のヤマト電気さんから麒麟印マホービン社へまほうびん70個の注文が入りました。(2009/10/06とします)
注文を受けた麒麟印社はクーペンギン物流倉庫に対して、ヤマト電気さんに70個の出荷依頼を出します。
決められた書式で出荷データを作成し、クーペンギン物流倉庫にコンピュータを利用してデータ送信します。
この場合も前述同様、電子データ(EDI)のやり取りが殆どです。


在庫管理その4

(4) クーペンギン物流倉庫はデータを受信後、在庫管理システムからコンピュータを利用して自動引き当てを行います。
この会社との引き当てルールは先入れ先出し、即ち古い入荷順から順番に引き当てを行います。

一番最初に入荷された古い在庫(ここでは明細行の1行目の2009/09/20の入荷データ)から引き当てします。
ちゃんと70個引き当てしてますね。


(5) 引き当てした段階で、出荷指示書(ピッキングリスト)や必要書類をプリントします。
必要書類とは納品書や受領書、宅配会社への送り状(配送伝票)などです。



(6) 梱包や内容検品など一連の出荷工程を行いトラックのドライバーに製品を渡します。



在庫管理その5

(7) トラックが出発すれば、ひとまず出荷作業は完了です。この地点で在庫を更新します。
出荷した70個が減っていますね。


順を追って説明すれば、理屈はとても簡単です。全然難しくありません。
しかし、現実の世界はこんなに簡単な例は まずありません。
こんなに簡単だったら在庫管理の必要性がありません。


少しづつデータを増やしていきます。
恐らくコンピュータシステムの必要性が実感出来るはずです。

120 在庫管理の基礎の基礎

06:物流システム

流通システム/物流システム徒然記

いきなりですが、オンラインショッピングで 前から欲しかった電子端末 を注文するとします。

お店が仕入れた電子端末は300個限定でした。
販売する前なので、まだ一度も注文を受けていません。

本日、オンライン出店すると低価格宣伝が功を奏し、注文が殺到して予約がどんどん入り、注文数235個、今現在のお店の在庫は65個になりました。(めでたい!)

これをシステム的に見ると・・・
現在の総在庫数量300個、実在庫数量65個になります。

在庫管理の基礎の基礎


掲載したイラストだと規模が大きく感じるかもしれませんが、個人で商品を取り扱う場合でも基本は同じです。

同じく例で話します。

商品が400個ありました。
125個の注文が入り、商品引当てを行いました。
この時点で在庫は、400-125=275個ですね。

即ち 在庫全体(On Hand)が 400個
引当て済み(Allocated)が 125個
引当て可能(Available)が 275個
となります。

とても簡単です。

この125個の注文が宅配便で配送すると手元の在庫が減って、
在庫全体(On Hand)が 275個
引当て済み(Allocated)が 0個
引当て可能(Available)が 275個
となります。


実際に引当て可能がAvailable(アベイラブル)、引当て済みはAllocated(アロケーテッド)、在庫全体がOn Hand(オンハンド)なんて呼ばれます。

「 何でわざわざ英語を使うの?」

深い理由はありませんが、大手などは海外のパッケージソフトを使ったなごりかもしれません。
日本で作ったシステムでも英語が使われることも少なくないようです。


製品が1種類だけなら話は簡単です。
しかし、大抵の場合は1種類の製品だけ取り扱うことはありません。
たとえ同じ種類だけであっても色やサイズや大きさや組み合わせがあったりします。

それが日々の入荷と出荷が同時発生します。
もし何十、数百の取扱い製品があったら間違いなく収拾がつかなくなります。
電卓と帳簿だけで在庫調整していたら絶対数量は合わなくなるでしょう。

「 在庫は合わないもの 」と考えられていたのは、システム導入が無かったひと昔前の話です。
今は企業どうしが電子データをやり取りしてモノが流れます。

このデータがEDIって言います。
まさにジャストインタイムでモノは流れます。
その流れを制御する物流部門がロジスティックスです。

これをシステムで制御しているだけです。
昨今はWEBを利用したXMLフォーマットによるデータ送受信が登場しています。

「 はあ、さようですか・・・ 」(こんな声が聞こえてきそうです)
一気に流しましたが、ゆっくり進めます。

119 在庫管理で企業の勝ち負けは決まるのだ

06:物流システム

流通システム/物流システム徒然記

ずっと倉庫業務の内容に触れていますが、倉庫業務の要となる在庫管理に触れます。
在庫管理と言っても、難しく語るつもりはありません。いつものように徒然に触れていきます。

私が20代の若かりしき頃、某化粧品メーカーの工場でシステム開発を行った経験があります。
原価管理、生産管理、作業管理など、まさに生産工場のシステムに関与していました。

その中で所要量計算なる仕組みがあったのですが、やたら難解なシステムだった記憶があります。今でも所要量計算は非常に理解に苦しみます。
工場の作業員は、時々コンピュータルームにやってきて何やら画面を確認します。

何を確認しているのかって言うと、化粧品の原料確認なんです。わざわざマシンルームの端末にやってきて、原料である香料の在庫量の確認に来るのです。
即ち、その数値は正確な値であることを意味します。(そうでなければ確認に来ません)

当時、それを何とも感じませんでしたが、今となっては凄いことだと思います。
何が凄いの?・・・と思う人は、在庫管理の難しさを知らない人です。


在庫管理



『一昔前は、在庫って合わないのが当たりまえ』くらい合わないものだったのです。(笑)

モノが入れば数字は増える、モノが出れば数字は減る・・・足し算と引き算だけの単純明快な世界です。
しかし、常に正確な数字を維持することは、経験した人しか分からない非常に大変なことなのです。


今更ながら、このシステムを作って管理運営されていた当時の担当者(課長)は凄い人だと思います。
当時、私がこの手の仕組みに興味を持っていれば、もっと貪欲に知識を吸収していたでしょう。今更ながら非常に悔やまれます・・・。


コンピュータの在庫数量が信用できず、実際に倉庫に行って在庫を確認する営業マンのいる企業って結構います。
自社の在庫数量をリアルタイムに正しく把握していないからです。

あなたの会社で、まさか倉庫担当者に在庫確認の電話していませんよね?この時点で負け組み企業になってしまいます。

そんな訳で、在庫管理を考察します。
個人的にも倉庫システムに於ける在庫管理はシステムは、最も得意とするテーマの一つです。

それでは徒然に語ります。

1 2 3 4 5 >