在庫管理
在庫管理とは、アイテムの供給、保管およびアクセス性を支えるすべてのプロセスであり、在庫コストを最小限に抑えつつアイテムの可用性を確保するものです。実際、在庫管理は、在庫の管理、アイテムの数量と保管場所の記録、さらには供給の最適化など多岐にわたる側面を含みます。
管理と最適化
在庫管理は広範な分野であり、大きく2つの領域に分けることができます:
- 在庫の管理は、ほとんどのコンピュータベースの環境において在庫管理ソフトウェアと切り離すことがほぼ不可能です。_在庫管理_の目的は、すべての在庫業務において高い生産性を維持することです。
- 在庫の最適化は、保管費用や品切れ費用などのコストを、不確実な未来需要に直面しながら最小限に抑えることを目指します。_在庫の最適化_の目的は、企業に対する在庫の財務的成果を最大化することです。
物理的には「一つ」の在庫であっても、これら二つの領域は根本的に異なる問題を反映しており、別々に対処する方が望ましいのです。
在庫の管理
近代的な形態においては、在庫の管理はそれを支える在庫管理ソフトウェアとほとんど区別がつかないほど一体化しています。実際、このソフトウェアは、在庫の電子的表現を保持し、通常は非常に長い物理的な在庫検査を省略して日常の問い合わせに即座に対応するために用いられます。例:製品Xの残りユニット数はどれくらいか?
在庫の正確な電子記録を維持するために、すべての在庫業務はソフトウェア上で記録されなければなりません。実際、バーコードやRFID(無線周波数識別)の利用によりデータ入力は大幅に高速化されます。最先端の環境1では、在庫そのものに対する物理的な操作がロボット化され、結果として在庫はエンドツーエンドでデジタル管理されます。
企業が管理する資産の正確な財務反映を重視する会計システムとは異なり、在庫管理システムは、企業が在庫を運用するための_行動志向_のシステムです。システムの第一の目標は生産性、すなわち、最小限の時間と労力であらゆる在庫業務を遂行することにあります。第二の目標は、物理的在庫の電子的表現の持続可能な正確性を確保することです。
在庫の最適化
在庫は将来需要の予測を反映しており、相反するコスト間の財務的なトレードオフとなります。在庫が過多であれば保管費用が急上昇し、在庫が不足すれば提供すべき商品がなくなり品切れコストが発生します。
在庫管理とは異なり、在庫の最適化は、以下のような最善の意思決定に焦点を当てます:
- いつ、どれだけ再発注するかの決定(リオーダー・ポイントも参照)
- 施設内でのアイテムの保管場所の決定
- どのアイテムをいつ計数するかの決定(ファントム在庫も参照)
- …
一旦意思決定が行われると、その決定は在庫管理システムを通じて実行されますが、システム自体がその意思決定を行ったり、オペレーターによる手動検証のための提案を生成したりするわけではありません。
在庫最適化問題の主要な課題は、未来需要に伴う不確実性です。実際、未来需要が未知であるため、ほとんどの在庫最適化手法は統計を用いて需要予測を行います。_最適化された_意思決定は、_期待される_将来コストを最小化するものとして算出されます。
時には、組み合わせ問題が最適化をさらに複雑にします。例えば、小売業者は出荷コストを最小限に抑えるために、在庫補充の注文を出し、配送に使用されるトラックの利用可能な全重量とスペースを活用しようとするかもしれません。実際、これは重いアイテムとかさばるアイテムの適切な組み合わせを選択することを意味します.
二つの視点の比較
上述の通り、在庫の管理と最適化は異なる問題です。以下の表は、両者間の主な相違点を概説しています。
管理 | 最適化 | |
---|---|---|
ソフトウェアの本質 | 機能重視。機能が充実しているほど、あまり頻繁でない状況に対してソフトウェアがより多くの支援を提供するため、生産性が向上します。 | パフォーマンス重視。ソフトウェアは、計算された意思決定の財務的パフォーマンスに基づいて評価されます。 |
組織への影響 | 高い。企業のほとんどの在庫プロセスはソフトウェア自体によって直接構築されています。 | 低い。在庫プロセスは既に存在しており、システムは単に代替の意思決定を提案するだけです。 |
運用可能性 | リアルタイム。ソフトウェアが利用できない場合、企業は文字通り在庫の運用が不可能となります。 | オフライン。ほとんどの在庫の意思決定は1日1回、あるいは2回行われ、バッチ処理で生成されることがあります。 |
計算負荷 | 低い。ソフトウェアは在庫の物理的な動きをその都度反映するだけで、現代のコンピュータで利用可能な処理能力と比べると非常に低速です。 | 高い。最適化を実行するため、ソフトウェアはシミュレーションまたはそれに類する処理を行い、全履歴を何度も再処理する必要があります。 |
変更コスト | 高い。すべてのプロセスがソフトウェアを中心に構成され、ソフトウェアが在庫の’‘状態’‘を表すため、在庫記録が急速に乖離してしまい、共存するシステムを運用するのは実用的ではありません。 | 低い。各システムに対して’‘適用可能な範囲’‘が定義されていれば、複数のシステムが共存可能であり、一つのシステムから次のシステムへ段階的に移行することも可能です。 |
Lokadの落とし穴
歴史的に、ERPは在庫管理と在庫最適化の両問題に対処するためのモノリシックなソリューションとして登場しました。しかし、前節で詳述したように、優れた在庫管理ソフトウェアに必要な_要素_は、優れた在庫最適化ソフトウェアに求められるものとは大きく異なります。その結果、モノリシックな設計を採用する企業の多くは、管理の不備または最適化の不備のいずれかに苦しむことが観察されます――後者が最も一般的です。
この問題は、ソフトウェア業界における変化の速度によってさらに際立たせられます。実際、在庫管理ソフトウェアはその性質上非常に_固定化_しやすく、一度採用されると変更コストが非常に高いため、大企業では代替ソリューションへの完全移行に最大10年かかることも日常的に観察されます。小規模な企業ではこの遅延は短くなるものの、複数年にわたる移行は一般的です。つまり、多くの企業が1〜2十年前の管理ソフトウェアを運用しており、現在市場に出回っているより優れたソリューションがもたらす便益を享受できていません。しかし、変更コストが高いため、ここでできることはほとんどありません。
これに対して、最適化部分は変更コストに関してはるかに低い摩擦で実施されます。実際、通常は各システムが独自の_提案_(例:再発注すべきアイテムのリスト)を生成し、それぞれのシステムにどの範囲の権限を与えるかを定めるプロセスが存在します。
注意
-
例えば、Kiva Systemsはモバイルを利用した注文履行システムを製造しています ↩︎