定量的サプライチェーン管理 vs クラシックAPS

Joannes Vermorel

サプライチェーンは1980年代および1990年代に、電子 inventory management やEDI（電子データ交換）によってデジタル化を早期に開始しましたが、多くの ソフトウェアベンダー ― そして結果的にそのクライアントのほとんども ― は、その後の20年間で次第に時代遅れとなっていきました。例えば、デスクトップアプリをウェブアプリに変えるなど、ユーザーインターフェースを刷新するのは比較的容易ですが、通常、ソフトウェアを支える コアなアーキテクチャ設計の選択肢 を再検討するのははるかに困難です。これらのソリューションのほとんどは、クラウドコンピューティング、機械学習、またはモバイルファーストのユーザー体験を前提として設計されていませんでした。

Lokadは、現代のネットワーク化されたコンピューティングパワーがサプライチェーンに提供できる恩恵を最大限に活用するプロセスとテクノロジーを提唱し、より優れた予測最適化を実現します。このアプローチを 定量的サプライチェーン の視点と呼んでいます。しかし、サプライチェーンの実務者にとって、このメッセージは多少混乱を招くかもしれません。なぜなら、Quantitative Supply Chainは従来のサプライチェーン最適化の変種ではなく、全く異なる存在だからです。

したがって、伝統的な モジュール を、通常¹ APS（先進計画およびスケジューリング）システムに見られるように、2層ネットワークにおける在庫 補充 ― 例えば、warehouses や店舗 ― に特に着目して詳しく見ていき、これらのモジュールをLokadの予測最適化手法と比較しましょう。要点を簡潔にするため、以下では 定量的サプライチェーン（ビジョン）またはLokad（ソフトウェア実装）の用語を交互に用います。

カレンダーモジュール

カレンダー モジュールは、固定注文サイクルが避けられない場合に、つまり いつ 購入するかを決定するための注文状況の微調整メカニズムを提供します。

サプライチェーン実務者が注文スケジュールを微調整すべきだという考え自体が、問題の正しい捉え方ではありません。注文には、カレンダー、MOQs、予算など、複数の制約が伴います。ある制約は「スケジュールなし、ただし7月4日と12月25日を除く」といった緩やかなものもあれば、「コンテナは正確に満杯でなければならない」といった厳格なものもあります。いずれにせよ、システムはすべての実行可能な注文オプションの中からROIを最大化するものを探すべきです。このプロセス、すなわち「最適化」は、厳格に自動化される べき です。手動での微調整を行う理由はありません。80年代には高性能な数値ソルバーが一般的ではなかったものの、現在ではそうではありません。

このように、Lokadでは関連するすべての制約を収集し、それ自体を データとして扱い ―すなわち許可された注文スケジュールの「データベース」― として管理し、適切な数値ソルバーを展開して作業を遂行します。

詳細は現代の供給チェーンにおける人間も参照してください。

イベントモジュール

イベント モジュールは、新製品の導入、広告、価格の プロモーション、カタログの配布やフライヤーなど、計画されたイベントによる需要の急増や急減を管理します。

1950年代や1960年代に発見された最初の予測モデル（例：Holt-Winters）はすべて 時系列 に基づいていました。したがって、多くのAPSは時系列中心の視点を採用しました。しかし残念ながら、供給チェーンの問題は容易に時系列に組み込めるものではなく、ストックアウト、プロモーション、導入、フェーズアウトといった現象は、従来の時系列に関連する数学的枠組みに適合しません。そのため、設計上壊れた時系列予測モデルに対処するため、APSは過去のプロモーションの影響を平滑化するなど、歴史データと需要予測の両方に手動の「補正」を加えるに頼っています。

Lokadでは、これらの「乱れ」を単なる履歴データとして扱うことを基本方針としています。過去のプロモーションが実施されなかった場合に何が起こったかを確実に知ることはできません。確実に把握できるのは、プロモーションの特性 ― すなわち開始日・終了日、割引メカニズム、適用範囲など ― と、それに伴う売上のみです。したがって、統計モデルは、狭い時系列の視点にとらわれることなく、存在する履歴データをそのまま処理できるように設計される必要があります。

Lokadは関連するイベントを収集し、これらのデータを高次元問題に対応した統計モデル、すなわち一般的に「機械学習」アルゴリズムの枠内で処理します。当社最新の予測技術は微分可能プログラミングを中心としています。しかし、機械学習分野自体が急速に進化しているため、これは依然として進行中の作業です。予測結果を手動で微調整する必要があるという状況は、サプライチェーン実務者を「人的補助プロセッサ」として活用する機会ではなく、修正すべきソフトウェアの欠陥とみなすべきです。

実際のところ、問題の大部分は、過去のイベントと将来のイベント（例：計画されたプロモーション）の関連データを収集することにあり、これは統計学とはほとんど関係がありません。また、LokadやAPSといった分析システムは、大量の手動データ入力を行うべき場所ではありません。これらのデータ入力は、サプライチェーンに関するすべての 事実² を収集するトランザクション領域、すなわち ERP に属します。

注文迅速化管理モジュール

注文迅速化管理 モジュールは、早期警告ツールとして機能し、買い手に毎日更新される滞納注文と不足出荷の状況を提供します。

例外 と アラート を用いるこのアプローチは、ソフトウェア業界の複雑なシステム内の問題を緩和するための、やや時代遅れの視点です。この手法は1980年代や1990年代にソフトウェアベンダーによって広く採用されました。なぜなら、SQLデータベース上で 例外 と アラート を実装するのは非常に簡単で、いくつかのWHERE条件を伴うSELECT文を実行するだけで済むからです。しかしながら、全体としてこのアプローチは、サプライチェーン実務者という貴重なリソースを過度に負担し、結果としてアラートが本来の「警告」として機能せず、緊急性や取るべき行動の感覚が失われてしまいます。

Lokadは、サプライチェーン実務者に提示される「対象」アイテムを、厳格なROIに基づいて優先順位付けすることを重視して提供します。一般的に、1日で100万の数値を生成するのは容易ですが、人間が読む価値のある10の数値を生成するのは困難です。滞納注文が常に重要であるとは限らず、例えばstock levels（在庫水準）が依然として高い場合や、そのサプライヤーにとってはこれまで繰り返されてきた問題である場合もあります。不足出荷も、サプライヤーへの支払い補正のため自動処理されるべきですが、必ずしも即時の対応を要求するものではありません。「アイテム」にROIが存在するためには、その「アイテム」が 実行可能 である必要があり、ROIはその行動に伴う推定ROIを表します。Lokadは、対象サプライチェーンの特性に正確に合わせた オーダーメイド の優先順位付けを提供することで際立っています。

ディール/フォワードバイモジュール

ディール/フォワードバイ モジュールは、買い手がディール期間の前にディールデータをシステムに入力できるようにします。これにより、システムはディールウィンドウに合わせた補充在庫の購入、フォワードバイ数量の計算およびその数量を購入する時期の決定を可能にします。

ほとんどのAPSは、最適な注文数量を計算するために、_単価_が価格面で自給自足であると単純に仮定するという視点で初期実装されました。しかし、現実はより詳細です。サプライヤーはしばしばMOQ、価格ブレイク、四半期ごとの割引、一時的なディールなど、複雑な価格体系を持っています。

Lokadはこれらすべての要素を 入力データおよび入力制約 として扱い、制約付き問題の直接的な数値解法を活用して、最適化された 注文数量を提供します。例えば、サプライヤーによる一時的な割引は、企業が一時的に過剰在庫を抱える経済的インセンティブをもたらします。すなわち、注文数量は、追加割引（線形の利益）と過剰在庫リスク（超線形のコスト）との間の数値的トレードオフとなります。私たちは、その他の関連する経済要因に加え、このトレードオフを直接最適化する注文数量を提供します。

注文分析モジュール

注文分析 モジュールは、潜在的な在庫切れを特定します。これらのモジュールは、輸入品やカスタム製造される長納期アイテム（しばしば2件、3件以上の注文が未処理）の在庫状況を把握するために必要な最新情報を提供します。

これは、いわゆる「実装の容易さ」を追求した単純なソフトウェア設計の一例です。1980年代にはネットワーク全体の分析を行うのが困難であったため、ほとんどのソフトウェアベンダーは「SKUの分離」を強制する設計を採用していました。各SKUは個別に処理され、次の注文サイクルにおける在庫切れ確率のような統計推定値は、対象となるSKU固有のものとなります。

Lokadでは、すべてのSKUが会社の予算を巡って互いに競争していると捉えています。したがって、特定のSKUの在庫切れ確率が高いか低いかは本質的な問題ではなく、重要なのは、そのSKUをさらに注文することで得られるリターンが、他のSKUから追加注文するという代替オプションに打ち勝つほど十分に高いかどうかです。たとえば、そのSKUが高コストで非常に低い利益率であり、なおかつ売上チームによれば間もなく唯一の大口企業の顧客が離れる場合、そのSKUのサービスレベルを維持することは、死蔵在庫を生み出す確実な方法となります。

実際、Lokadはサプライチェーン全体の経済性を直接反映する 優先順位付けされた注文数量 を提供します。

過剰在庫転送モジュール

過剰在庫転送 モジュールは、買い手が倉庫内の過剰在庫を管理するのに役立ちます。これにより、買い手は需要が十分な別の場所へ余剰在庫を移動させ、追加購入を回避できます。

サプライチェーンにおいて、場所Aから場所Bへ何かを移動させることはほぼ常に 可能 ですが、通常は 採算が取れる とは限りません。したがって、同じ商品が複数の場所に保管可能なネットワークでは、任意の2拠点間の在庫移動を 潜在的な 決定とみなすのが自然です。

このように、Lokadはネットワークレベルでこの種の最適化を実行する機能を内蔵しており、基本的には在庫移動のあらゆる選択肢を総当たりで探索します。その中で最も難しい部分は、在庫移動に伴う 経済的摩擦 を適切に反映することです。実際、摩擦は通常SKUレベルでの在庫移動では十分に反映されません。例えば、輸送費は非常に非線形であり、トラックを派遣する場合は、その利用可能な容量を最大限に活用すべきです。

残念ながら、選択肢 の数はSKUの数よりもはるかに速く増加します。例えば、10の倉庫に2000アイテムが保管されているネットワークでは、合計で10 x 2000 = 20,000のSKUが存在します。在庫移動で考慮すべき エッジ の総数は 10 x (10 - 1) x 2000 = 180,000エッジとなり、元のSKU数を大きく上回ります。アルゴリズムに精通している読者にとって、これは二次計算量の典型的なケースです。

しかし、今日利用可能な処理能力を考慮すれば、このような二次計算量のケースは、基盤となるソフトウェアがこの種の数値探索に適切に設計されていれば、ほとんど問題になりません。実際、サプライチェーンネットワークは、たとえ最も巨大な企業であっても通常10,000拠点を超えることはなく、また多くの拠点の組み合わせは、パリとシドニー間の在庫再調整のように無意味なため、実際に探索すべき エッジ の数を大幅に減らすためのいくつかのヒューリスティックが利用可能です。

しかし、1980年代や1990年代には、当時利用可能なコンピューター・ハードウェアの制約から、APSはすでにSKUの数への対処に苦労していました。当然、この文脈では、二次計算量の問題に対処することは全く現実的ではありませんでした。

現代に至るまで、多くのベンダーはネットワーク全体の最適化を伴ういかなる問題にも対処するため、別個のモジュールを導入せざるを得ませんでした。しかし、別個 のモジュールを持つことに実際のビジネス上の動機はなく、この状態はもともとのベンダーが20年前の設計選択と矛盾する問題に対処するため、ソフトウェア製品に応急措置を施していることの表れです。

これに対して、Lokadは当社のソフトウェアスタックにおいて主要な位置を占めるこの種の問題に真正面から取り組むことを決定しました。当然、実際の課題解決には、すべての輸送コストと制約を明示する必要があるため、依然として実務上の努力が伴います。

プランニングモジュール

プランニング モジュールは、営業チームやマーケティングチームが、プロモーションや特別注文などの特定のイベントに備えて注文を事前に計画できるようにします。チームは、計画された注文日の1年以上前にシステム上で計画注文を作成することができます。

Lokadのアプローチは、事実 と 予測 を明確に分離することから始まります。B2B小売ネットワークを例にとると、もし顧客が2月10日に3月1日納品予定で1000ユニットの注文を発表した場合、その発表は 事実 となります。そして、もしその顧客が直前に納品予定日を再検討する傾向（通常1週間の延期）があるなら、そのパターンも考慮に入れる必要があります。しかし、このパターン分析は問題の 予測 側に分類されます。

Lokadは、このクラスの問題に対して 一般的確率予測 だけでなく 需要確率予測 を提供する技術で取り組みます。将来についてのいかなる主張、例えば予想される到着日も、ある程度の不確実性を伴います。サプライチェーンには多用途の高次元予測ツールが必要とされるため、まさにその理由でLokadは 微分可能プログラミング の道を選びました。

また、事実は分析レイヤーによって収集されるべきではありません。これはLokadもAPSも同様です。ソフトウェアがそれを実行できないからではなく、事実を収集するソフトウェアの設計は比較的容易ですが、大量の 偶発的なベンダーロックイン を生み出すためです。実際、社内のシステムを通じてデータエントリが流れると、そのシステムがこのデータの de facto マスターコントローラーとなります。

Lokadでの経験から、陳腐化した分析レイヤーは、システムを停止すればミッションクリティカルなデータが失われるという理由だけで、陳腐化してからさらに10年も残り続けることがよくあります。一方で、元のソフトウェアベンダーは保守費用を引き続き徴収し、それがそもそもの問題を作り出す大きなインセンティブとなっています。

Projections module

プロジェクション モジュールにより、購入者は最大1年前までの将来の需要および将来の購入を予測するレポートを作成することが可能です。これらの予測はサプライヤーと共有され、各サプライヤーが自社の供給能力をより正確に計画できるようになります。

裸の予測は有害であり、もはや健全なサプライチェーンの慣行とは考えられません。詳細については、裸の予測アンチパターンを参照してください。これは、Lokadに予測能力がないという意味ではなく、予測能力はあるということです。しかし、私たちは従来の時系列予測手法は単に誤っており、終わらせるべきだと主張しています。従来の時系列予測は非常に大量で非常に安定した製品には有効かもしれませんが、それ以外の場合、特に不規則または断続的な需要では確率的予測が最適な方法です。

さらに、ホルト・ウィンター法やARIMAなどの従来の時系列予測モデルは、製品の履歴が短すぎたり、不規則すぎたり、典型的でなかったり、取扱量が少なすぎる場合に大きな欠点を抱えていました。ほとんどのソフトウェアベンダーはこれらの問題に対し、各々に機能不全を招く以下の2つのアプローチで対応しました：

• ヒューマン・コプロセッサー: 予測モデルがしばしば意味不明な結果を出すため、システムは人間のオペレーター、すなわちプランナーを「コプロセッサー」として用い、「数字がしっくり来ない」場合に手動で予測を上書きさせます。残念ながら、予測は継続的に更新されなければならず、プランナーは手動での上書きという終わりのないサイクルに陥ります。この作業はまた、予測が間違っていると常に見なすようになり、実際には正しい場合でも純粋な直感で修正してしまうという望ましくない副作用を生み出します。
• モデル競争: 各時系列予測モデルにはそれぞれ長所と短所があるため、多数の予測モデルが競争することで、システムが各状況で最適なモデルを「選ぶ」ことで良い結果が得られるはずという考え方です。しかし、これは二つの理由で失敗します。第一に、すべてのモデルが 時系列 の枠組みに依存しており、同じ制約を受けるためです。第二に、どのモデルも「クラシック」であり、サプライチェーンに必要な確率的予測を提供できないのです。

さらに、予測は需要だけに関するものではありません。リードタイムも予測されるべきです。また、サプライチェーンの 構造 も重要です。B2Bでは、安定した売上が、すべての注文が同一のクライアントからのものであるという事実を隠してしまうことがあります。このクライアントを失うと、多くのアイテムが即座に在庫過剰、あるいは死蔵在庫となります。サプライチェーンの適切な 予測的最適化 は、このリスクを考慮に入れなければなりません。Lokadの技術はその点において適切に設計されています。

サプライヤーと予測を共有するという観点では、買い手とサプライヤー間の連携がより良好であることは常に望ましいですが、企業間で成功する 予測駆動型 の連携は極めて稀であることが観察されています。サプライヤーはもともと多数のクライアントを抱えているため³、たとえ現地の買い手から提供された予測が正確であったとしても、サプライヤーはそれらのばらばらな予測を統合する方法を持たないのです：予測の合計が合計の予測ではない。

Security module

驚くべきことに、一部のAPSでは セキュリティ 機能がシステムにデフォルトで備わっておらず、別個のモジュールとして提供されています。セキュリティモジュールの目的は、一部のユーザーのアクセスを防ぐことにあります。また、会社の制御要因、アイテム保守、サプライヤー保守、注文、取引その他の重要な領域において、管理側がコンポーネントの操作を保護し閲覧を制限することを可能にします。

ソフトウェア用語で言えば、ここで取り上げているのは認証と認可という横断的な懸念事項です。

• 認証 は、システム内で何かを行うエンドユーザーが、本当にシステムが信じるその人物であることを保証します。ここで、Lokadは認証は可能な限り 委任されるべき であるという現代的なアプローチを採用しています。エンドユーザーがさらに別のパスワードを管理する必要がないようにするためです。代わりに、Lokadはフェデレーテッドアイデンティティ管理（FIM）に認証を委任するためにSAMLを de facto 業界標準として活用します。
• 認可 は、システム内で 誰が何をできるか についての細かな制御を提供します。ここで、Lokadは広範な標準ACL（アクセス制御リスト）システムを備えており、これは現代企業システムにおける de facto の慣行でもあります。さらに、Lokadはユーザーエクスペリエンスの観点からACLを補完するパーソナライゼーション機能も備えています。

Lokadは、どのパッケージがお客様に販売されたかに関わらず、すべてのセキュリティ機能をデフォルトで有効化します。私たちは、オプショナルセキュリティ⁴ をソフトウェアベンダーが採用するのは酷い慣行だと考えています。ソフトウェアの保護は元々非常に困難であり、その慣行は状況をさらに悪化させるだけです。

正直に言えば、ACLに関する視点は ソフトウェアセキュリティ 全体の中で最も厄介でない問題です。より興味深いのは、システムのアーキテクチャ自体がどれほどの セキュリティ・バイ・デザイン を提供しているかという点です。しかし、この問いに答えることは本記事の範囲を超えています。

Export to Excel

Excelへのエクスポート モジュールは、他のシステムまたは分析の目的でデータを移送する簡便な方法を提供します。

Excelシートの作成は比較的容易であるため⁵、Lokadを含む多くのベンダーがこの分野での機能を提供しています。しかし、詳細に検証すると、多くのベンダーが中途半端な機能しか提供していないことが分かります。ここで、優れた Excelエクスポート実装の際立った要点を見てみましょう：

• 完全な履歴管理: システムは、これまでにエクスポートされたすべてのExcelシートを追跡し、再ダウンロードできる機能を提供すべきです。実際、スプレッドシート上の数字に誤りが生じた場合（たとえデータ入力の誤りによるにせよ）に、このスプレッドシートを生成したコード経路の完全な追跡がなければ、問題のデバッグや修正の試みが大幅に複雑化、遅延、あるいは時には不可能となるでしょう。
• スプレッドシートの能力の最大活用: 実務者は、実際にはExcel自体の上限である最大100万行の 大容量 スプレッドシートを生成できることを期待しています⁶。したがって、システムは、慣れ親しんだツール内で自らデータ解析を行いたい実務者の邪魔をしないよう、重厚なスプレッドシートを生成できなければなりません。言うまでもなく、実務者はこれらの大容量エクスポートが迅速であることも期待しています。
• スプレッドシート攻撃に対する組み込み保護: Excelは大規模組織にとって危険な攻撃経路となりえます。残念ながら、システムが生成するスプレッドシートのセキュリティは後付けにできず、初日から設計の不可欠な部分として組み込まれていなければなりません。
• エクスポートのプログラム的構成可能性: APSとExcelという二つのソフトウェアを扱うだけでも供給チェーンの実務者にとっては十分な苦労ですが、常に追加の抽出後処理を必要とするスプレッドシートによって状況が悪化すべきではありません。これは、すべての処理が抽出 前 にAPS内で行われるべきことを意味します。したがって、APSはエクスポート前にスプレッドシートを適切に準備するためのプログラム的機能を必要とします。

Lokadは上記すべてを提供する一方で、多くの競合他社はそうではありません。問題は細部に宿ります。

Conclusion

私たちは、Lokadが市場のほとんどのAPSよりも シンプル なソフトウェアであると確信しています。しかし、予測技術を通じたサプライチェーンパフォーマンスの提供能力は、それ以上に高いものがあります。実際、APSの複雑さの多くは 偶発的 であり、数十年前に内向きなソフトウェア問題に対処するために行われた設計選択に起因しています。しかし、一度採用された多くのソフトウェアのアーキテクチャ上の選択は、取り消すことができません。