在庫管理

Joannes Vermorelによる、2013年6月

供給、保管、アイテムのアクセシビリティをサポートし、在庫コストを最小限に抑えながらアイテムの利用可能性を確保するためのすべてのプロセス。実際には、在庫管理には在庫の管理、数量と場所の両方の記録だけでなく、供給の最適化も含まれます。

管理 vs 最適化

在庫管理は、2つの主要な領域に分割できる広範なドメインです：

在庫の管理は、ほとんどのコンピュータベースのセットアップでは在庫管理ソフトウェアと切り離すことがほとんど不可能です。在庫を「管理」する際の目標は、すべての在庫操作の高い生産性を維持することです。
在庫の最適化では、在庫の保有コストや欠品コストなどのコストを最小限に抑えながら、不確実な将来の需要に対処する必要があります。在庫を「最適化」する際の目標は、企業の財務的なアウトプットを最大化することです。

物理的には「1つ」の在庫しかないですが、これらの2つの領域は根本的に異なる問題を反映しており、それらは別々に対処する方が良いです。

在庫の管理

現代の形態では、在庫の管理は在庫管理ソフトウェアとほとんど区別がつかないです。実際に、ソフトウェアは在庫の電子的な表現を保持し、在庫自体の非常に長い物理的な検査を必要とするルーチンの質問に即座に対応するために常に使用されます。例：製品Xの残りの単位数はいくつですか？

正確な在庫の電子的な記録を維持するためには、すべての在庫操作をソフトウェアで記録する必要があります。実際には、バーコードやRFID（無線周波数識別）の使用により、データの入力は大幅に加速されます。最も現代的な環境では¹、在庫自体で行われる物理的な操作はロボット化されており、在庫は真にエンドツーエンドでデジタル的に管理されます。

会社が管理する資産の正確な財務的な反映を提供することに焦点を当てる会計システムとは異なり、在庫管理システムは会社が在庫を運用するのをサポートするための「アクション指向」です。システムの第一の目標は生産性であり、つまり、最小限の時間や労力ですべての在庫操作を実行することです。システムの第二の目標は、物理的な在庫の電子的な表現の持続的な正確性を提供することです。

在庫の最適化

在庫は将来の需要の予測であり、競合するコストの金融的なトレードオフです。在庫が多すぎると、保有コストが急上昇します。在庫が少なすぎると、もはや提供するものがなくなり、欠品コストが発生します。

在庫管理とは異なり、在庫最適化は以下のような在庫を管理するための最善の意思決定に焦点を当てています：

いつ、どれだけ再発注するかを決定する（再発注ポイントも参照）
アイテムを施設内のどこに保存するかを決定する
どのアイテムをいつカウントするかを決定する（ファントム在庫も参照）
…

決定が下されると、在庫管理システムを通じて実行されます。ただし、管理システムはそのような決定を行う責任を持つわけではなく、オペレータによって手動で検証される提案を生成する責任も持ちません。

在庫最適化問題の主な課題は、将来の需要に関連する不確実性です。実際には、将来の需要が不明なため、ほとんどの在庫最適化技術は需要を予測するために統計を利用しています。最適化された意思決定は、将来のコストを最小化するものとして計算されます。

また、組み合わせ問題によって最適化がさらに複雑になることもあります。たとえば、小売業者は、配送に利用されるトラックの重量とスペースを最大限に活用するために、補充注文を行い、出荷コストを最小限に抑えたいと考える場合があります。実際には、重いアイテムとかさばるアイテムの適切な組み合わせを選ぶことを意味します。

2つのビジョンの比較

上記のように、在庫の管理または最適化は異なる問題です。以下の表は、2つの視点の主な違いを示しています。

	管理	最適化
ソフトウェアの本質	機能駆動。機能が多いほど、ソフトウェアはより頻度の低い状況に対するサポートを提供するため、生産性が高くなります。	パフォーマンス駆動。ソフトウェアは、ソフトウェアによって計算された意思決定の財務パフォーマンスに基づいて評価されます。
組織への影響	高い。会社のほとんどの在庫プロセスは、ソフトウェア自体によって直接構造化されています。	低い。在庫プロセスは事前に存在し、システムは単に代替の意思決定を提案するだけです。
運用の可用性	リアルタイム。ソフトウェアが利用できない場合、会社は文字通り在庫を運用することができません。	オフライン。ほとんどの在庫の意思決定は、1日に1回、場合によっては2回行われ、バッチで生成することができます。
計算負荷	低い。ソフトウェアは、物理的な在庫の動きを反映するだけであり、現代のコンピュータの処理能力と比較して非常に遅いです。	高い。ソフトウェアは、最適化を実行するために、頻繁にシミュレーションや同等の処理を行い、履歴全体を何度も再処理する必要があります。
変更のコスト	高い。すべてのプロセスがソフトウェアによって構造化されているため。在庫レコードがすぐに異なる方向に進むため、在庫の’‘状態’‘を表すソフトウェアとしての存在は実際には非現実的です。	低い。適用範囲が各システムに定義されている限り、複数のシステムが共存することができます。徐々に次のシステムに移行することも可能です。

Lokadの注意点

過去には、ERPは一体型のソリューションとして登場し、在庫管理と在庫最適化の問題の両方を解決するために使用されていました。しかし、前のセクションで詳しく説明したように、在庫管理ソフトウェアを作るために必要な「材料」と、在庫最適化ソフトウェアを作るために必要な「材料」は非常に異なります。その結果、一体型の設計を採用する企業のほとんどは、管理が悪いか最適化が悪いという問題に直面しています - 後者が最も頻繁なケースです。

この問題は、ソフトウェア業界の変化の速さによってさらに強調されています。実際、在庫管理ソフトウェアは非常に「粘着性のある」ソフトウェアです。一度採用されると、変更のコストが非常に高いため、大企業では代替ソリューションへの完全な移行に最大で10年かかることがよくあります。小規模企業の場合は、移行にかかる期間は短くなりますが、数年にわたる移行は頻繁に行われます。これは、多くの企業が10年以上前の管理ソフトウェアを使用していることを意味します - 現在市場で利用可能なより良いソリューションがもたらす利点を失っています。ただし、変更のコストが高いため、ここではほとんど何もできません。

対照的に、**最適化部分は変更のコストに関してははるかに低い摩擦力を持っています。**実際、複数のシステムを持つことができ、それぞれが独自の一連の「提案」（例：再注文するアイテムのリスト）を生成し、どのシステムにどの範囲の権限を与えるかを定義するプロセスを確立することが通常可能です。

ノート

たとえば、Kiva Systemsはモバイルを使用した受注処理システムを製造しています。 ↩︎