Quantitative SCM vs Classic APS

Joannes Vermorel

サプライチェーンは80年代と90年代に電子的な在庫管理とEDI（電子データ交換）によるデジタル化が始まりましたが、その後の20年間で多くのソフトウェアベンダー（およびそのクライアントのほとんど）は時代に取り残されてしまいました。たとえばデスクトップアプリをウェブアプリに変換するなど、ユーザーインターフェースを簡単に更新することは比較的簡単ですが、クラウドコンピューティング、機械学習、モバイルファーストのユーザーエクスペリエンスをサポートするためのコアアーキテクチャ設計の選択肢を見直すことは通常ははるかに困難です。

Lokadは、現代のネットワーク化されたコンピューティングパワーが供給チェーンにもたらす予測的な最適化を最大限に活用するプロセスと技術を提唱しています。私たちはこれを「定量的サプライチェーン」の視点と呼んでいます。しかし、サプライチェーンの実践者にとっては、このメッセージはやや混乱するかもしれません。なぜなら、「定量的サプライチェーン」はサプライチェーンの最適化の古い方法のバリエーションではなく、まったく異なるものだからです。

したがって、以下では、主に2階層ネットワーク（たとえば倉庫や店舗）における在庫の補充に焦点を当て、主要な¹ APS（先進的な計画とスケジューリング）システムで通常見られる伝統的な「モジュール」をLokadの予測的最適化の方法と比較してみましょう。簡潔さのために、以下では「定量的サプライチェーン」（ビジョン）またはLokad（ソフトウェアの実装）という用語を交換して使用します。

カレンダーモジュール

「カレンダーモジュール」は、固定注文サイクルが避けられない注文状況を微調整するメカニズムを提供します。

サプライチェーンの実践者が注文スケジュールを微調整する必要があるという考え方は間違っています。注文にはカレンダー、MOQ（最小発注量）、予算など、複数の制約があります。いくつかの制約は緩やかなものであり、「スケジュールはなく、7月4日と12月25日以外のどの日でも可能」といったものです。また、いくつかの制約は厳格なものであり、「コンテナは正確に満杯でなければならない」といったものです。いずれの場合でも、システムはROIを最大化するために、すべての実行可能な注文オプションの中から適切なものを探すべきです。このプロセス、つまり「最適化」は、厳密に自動化されるべきです。パフォーマンスの良い数値ソルバーは80年代には一般的ではありませんでしたが、現在ではそうではありません。

したがって、Lokadでは、関連する制約をすべて収集し、それ自体が「データ」として扱われる、つまり許可された注文スケジュールの「データベース」を作成し、適切な数値ソルバーを展開して仕事を完了させます。

また、現代のサプライチェーンにおける人間も参照してください。

イベントモジュール

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

最初の予測モデル（例：ホルト・ウィンタース）は、50年代と60年代に発見され、すべて時間系列を中心にしていました。したがって、ほとんどのAPSは時間系列中心の視点を採用しました。残念ながら、サプライチェーンの問題は時間系列に簡単にフレーム化することはできません。ストックアウト、プロモーション、導入、廃止などは、時間系列に関連付けられる伝統的な数学的フレームワークに適合しない現象です。したがって、壊れた時間系列予測モデルに対処するために、APSは手動の「修正」を採用し、過去のデータ（過去のプロモーションのアップリフトを平滑化するなど）と需要予測（将来の推定値にバイアスを導入するなど）の両方に適用します。

Lokadでは、これらの「乱れ」を単なる過去のデータとして扱います。過去のプロモーションがトリガーされなかった場合に何が起こったかは確かにわかりません。わかっていることは、プロモーションの特性（開始日と終了日、割引メカニズム、範囲など）とその結果の販売です。したがって、統計モデルは、狭い時間系列の視点に「固執」するのではなく、存在する歴史データを処理するために正面から設計する必要があります。

Lokadは関連するイベントを収集し、これらのデータを高次元の問題に対応する統計モデルで処理します。これは一般的な「機械学習」アルゴリズムの範疇に属しています。最新バージョンの予測技術は、微分可能プログラミングに重点を置いています。ただし、機械学習の分野自体が急速に進化しているため、まだ進行中の作業です。予測結果を手動で微調整する必要性は、サプライチェーンの専門家を「人間のコプロセッサー」として活用する機会ではなく、修正すべきソフトウェアの欠陥として扱うべきです。

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

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

「注文の迅速化管理」は、早期警告ツールとして機能し、バイヤーに遅延注文と不足出荷の毎日更新されるビューを提供します。

ソフトウェア業界では、複雑なシステム内の問題を緩和するための「例外」と「アラート」のアプローチは、かなり時代遅れの視点です。このアプローチは、80年代と90年代にソフトウェアベンダーによって広く採用されました。なぜなら、「例外」と「アラート」はSQLデータベースの上に簡単に実装できるからです。わずかなWHERE条件を持つSELECTステートメントだけで済みます。しかし、全体として、このアプローチはサプライチェーンの専門家が持つ貴重なリソースを効果的に活用していないため、すぐに彼らを過負荷にしてしまい、アラートはもはや「アラート」ではなくなり、緊急性や対応すべき行動の感覚が失われてしまいます。

Lokadは、サプライチェーンの専門家に提示される「興味のあるアイテム」の厳格なROIベースの優先順位付けを支持し、提供します。一般的な目安として、1日に100万の数字を生成することは簡単ですが、人間が読む価値のある10の数字を毎日生成することは困難です。遅延注文が常に重要であるわけではありません。たとえ在庫レベルがまだ高い場合でも、またはこれがずっと続いているサプライヤーの定期的な問題である場合もあります。不足出荷も自動的に処理され、サプライヤーへの支払いが適切に修正されるべきですが、常に即時の対応を必要とするわけではありません。ROIを持つためには、「アイテム」が「アクション可能」であり、ROIはそのアクションに関連する推定ROIを表します。Lokadは、特定のサプライチェーンの特異性に完全に合わせた「特注」の優先順位付けを提供することで輝きます。

取引/フォワードバイモジュール

「取引/フォワードバイ」タイプのモジュールでは、バイヤーが取引期間の前にシステムに取引データを入力できます。これにより、システムは取引ウィンドウに一致する補充在庫を購入し、フォワードバイ数量を計算し、これらの数量をいつ購入するかを決定できます。

ほとんどのAPSは、最適化された注文数量を計算するために、_単価_が自己完結的であるという単純化された視点で最初に実装されました。しかし、現実はより詳細なレベルを持っています。サプライヤーは頻繁に複雑な価格体系を持っています：MOQ、価格ブレーク、四半期のノルマに対する割引、一時的な取引など。

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

注文分析モジュール

「注文分析」モジュールは、在庫切れの可能性を特定します。これらのモジュールは、輸入品やカスタム製造品などのアイテムの在庫状況を理解するために必要な最新の情報を提供します。これらのアイテムは、通常、2つ、3つ、またはそれ以上の未処理の注文がある長いリードタイムのアイテムです。

これは、ある意味で単純化された「実装の容易さ」に基づくソフトウェア設計の別の例です。80年代には、ネットワーク全体の分析を行うことは困難でしたので、ほとんどのソフトウェアベンダーは「SKUの分離」を強制するソフトウェア設計を採用しました。各SKUは個別に処理され、次の注文サイクルの在庫切れ確率などの計算された統計的推定値は、対象のSKUに完全に特化しています。

Lokadでは、すべてのSKUが会社の予算と競合していることを観察しています。したがって、特定のSKUの在庫切れ確率が高いか低いかはあまり重要ではありません。重要なのは、このSKUの追加注文の回収が、会社にとって利用可能な他のオプション（別のSKUからの追加注文など）によって競合されないほど十分に高いかどうかです。たとえば、SKUが高コストで非常に低い利益を持ち、販売チームによれば単一の大企業の顧客からのみ購入される製品に関連付けられている場合、このSKUのサービスレベルを維持することは、死んだ在庫を作り出す確実な方法です。

Lokadは、サプライチェーンのエンドツーエンドの経済を直接反映した優先された注文数量を提供しています。

在庫超過転送モジュール

_在庫超過転送_モジュールは、バイヤーが倉庫内の在庫超過を管理するのに役立ちます。バイヤーは、追加の購入を避けるために、需要が十分な別の場所から余剰在庫を別の場所に転送することができます。

サプライチェーンでは、通常は場所Aから場所Bに何かを移動することはほぼ常に可能ですが、通常は利益になりません。したがって、同じアイテムを多くの場所に保存できるネットワークに直面する場合、任意の2つの場所間の在庫移動を潜在的な決定として扱うのは当然のことです。

したがって、Lokadには、在庫移動のすべての利用可能なオプションを総当たりで試すネットワークレベルの最適化の機能が組み込まれています。この取り組みの最も困難な部分は、在庫移動に関連する_経済的な摩擦_を適切に反映することです。実際には、在庫レベルでは摩擦は通常適切に反映されません。たとえば、輸送コストは非常に非線形になる傾向があります。トラックを派遣する必要がある場合は、その利用可能な容量を最大限に活用しましょう。

残念ながら、_オプション_の数はSKUの数よりもはるかに速く増加します。10個の倉庫に2000個のアイテムが格納されているネットワークを考えてみましょう。合計で10 x 2000 = 20,000のSKUがあります。在庫移動のために考慮する_エッジ_の総数は10 x (10 - 1) * 2000 = 180,000のエッジであり、元のSKUの数よりもはるかに多いです。アルゴリズムに詳しい読者にとっては、これは二次の複雑さの簡単なケースです。

しかし、現在の処理能力を考えると、この特定の二次の複雑さはほとんど問題ではありません - 前提として、基礎となるソフトウェアがこの種の数値探索に適切に設計されている場合です。実際、サプライチェーンネットワークは非常に稀に10,000以上の場所に達することはほとんどありません。最も巨大な企業を見ても、実際には探索する_エッジ_の数を劇的に減らすためにいくつかのヒューリスティックスを使用できます。なぜなら、パリとシドニーの間で在庫を再調整するなど、多くの場所のペアは無意味であることが予想されるからです。

ただし、80年代と90年代には、当時のコンピューティングハードウェアの制約により、APSは既にSKUの数に対処するのに苦労していました。この文脈では、二次の複雑さの問題に対処することは不可能でした。

現在、多くのベンダーは、ネットワーク全体の最適化を伴う問題に対処するために別々のモジュールを導入する必要がありました。別々のモジュールを持つことには、実際のビジネス上の動機はありません。この状況は、元のベンダーが20年前に行われた設計の選択肢と競合する問題のクラスに対処するために、ソフトウェア製品をダクトテープで修正してきたことを反映しています。

対照的に、Lokadは、この問題のクラスに直面するためのソフトウェアスタックの第一級の市民であるという問題に正面から取り組むことを決定しました。もちろん、この課題の実際の解決には、輸送コストと制約条件を明示する必要があります。

プランニングモジュール

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

Lokadのアプローチは、_事実_と_予測_の明確な区別を確立することから始まります。B2B小売ネットワークを考えてみましょう。クライアントが2月10日に1000ユニットの注文をすると発表し、予定された納品日が3月1日である場合、この発表は_事実_です。このクライアントが最後の瞬間に納品日を見直す習慣がある場合（通常は1週間延期する）、このパターンを考慮に入れる必要があります。ただし、このパターン分析は問題の_予測_側に属します。

Lokadは、_需要の確率的予測_だけでなく、_一般的な確率的予測_を提供する技術によって、このような問題のクラスに取り組んでいます。将来に関するいかなる声明も、到着予定日など、ある程度の不確実性を持つ傾向があります。サプライチェーンには、多目的で高次元の予測ツールが必要です。これが、Lokadが_微分可能プログラミング_の道を進んだ理由です。

また、事実は分析レイヤーによって収集されてはなりません。LokadもAPSもそうです。ソフトウェアがそれを行うことができないわけではありません。事実を収集するためのソフトウェアの設計は比較的簡単ですが、それによって_偶発的なベンダーロックイン_が発生します。実際、会社内のシステムを介してデータが流れると、そのシステムはこのデータの_事実上のマスターコントローラー_になります。

Lokadの経験では、時代遅れの分析レイヤーは、使い物にならなくなった時点からさらに10年以上も残り続けることがよくあります。なぜなら、このシステムをオフにすると、ミッションクリティカルなデータが失われるからです。一方、元のソフトウェアベンダーはまだメンテナンス料金を集めており、これによりベンダーは最初から問題を作り出す大きなインセンティブを得ています。

プロジェクションモジュール

_プロジェクション_モジュールでは、バイヤーが将来の需要や将来の購入を1年先まで予測するレポートを作成することができます。これらの予測はサプライヤーと共有することができ、それによりサプライヤーはそれぞれの供給能力をより正確に計画することができます。

裸の予測は有害であり、正常なサプライチェーンの実践とは見なされなくなりました。詳細については、裸の予測のアンチパターンをご覧ください。これは、Lokadに予測能力がないことを意味するものではありません。予測能力はあります。ただし、古典的な時系列予測手法は単純に間違っており、終了する必要があります。古典的な時系列は非常に高いボリューム、非常に安定した製品に対しては機能するかもしれませんが、それ以外の場合、特に不規則または断続的な需要に対しては、確率的予測が適しています。

さらに、過去の時系列予測モデル（例えば、Holt-WintersやArima）は、製品の履歴が短すぎたり、不規則すぎたり、典型的でなかったり、ボリュームが低すぎたりする場合には、大きな欠点がありました。多くのソフトウェアベンダーは、これらの問題に対して2つのアプローチで対応しましたが、それぞれが自己の方法で機能不全でした：

• 人間のコプロセッサ：予測モデルが頻繁に無意味な結果を出すため、人間のオペレータ（つまり、プランナー）は「数字が正しく感じられない」ときに予測を手動で上書きするためにシステムによって使用されます。残念ながら、このタスクは終わりがありません。予測を継続的に更新する必要があり、プランナーは絶え間ない手動の上書きサイクルに追われることになります。このようなタスクは、人間のオペレータが予測が間違っていると考え、純粋な直感に基づいている場合でも、予測が間違っていると考えるようになる望ましくない副作用も生み出します。
• モデル競争：各時系列予測モデルにはそれぞれ強みと弱点がありますので、多くの予測モデルの競争は、システムがすべての状況で最適なモデルを「選ぶ」ことによって良い結果を生むはずだという理論に基づいています。残念ながら、これは2つの理由で失敗します。まず、すべてのモデルが_時系列_フレームワークに依存しているため、すべてのモデルは同じ制約に従っています。第二に、すべてのモデルは「クラシック」であり、サプライチェーンが必要とする確率的な予測を提供することができません。

さらに、予測は需要に関するものだけではありません。リードタイムも予測する必要があります。また、サプライチェーンの_構造_も重要です。B2Bでは、一定の売上があれば、すべての注文が同じクライアントから発生していることを隠すことができます。このクライアントが失われると、多くのアイテムが在庫過多になるか、在庫切れになります。サプライチェーンの適切な_予測最適化_は、このリスクを考慮に入れる必要があります。Lokadのテクノロジーはそれに応じて設計されています。

供給業者との予測の共有の特定の観点では、バイヤーと供給業者の間のより良い調整は常に望ましいですが、私たちは成功した予測駆動型の企業間の調整はほとんどないことを観察してきました。供給業者には独自の多くのクライアントがいます³。したがって、現地のバイヤーが提供する予測が正確であっても、供給業者はそれらの異なる予測を調和させる方法を持っていません：予測の合計は合計の予測ではありません。

セキュリティモジュール

驚くべきことに、一部のAPSでは、_セキュリティ_機能がシステムにデフォルトで備わっていない場合があり、別のモジュールとして提供されています。セキュリティモジュールの目的は、一部のユーザーのアクセスを制限することです。また、管理者はコンポーネントのアクションを保護し、システムの重要な領域（企業の制御要素、アイテムのメンテナンス、ベンダーのメンテナンス、注文、取引など）の表示を制限することができます。

ソフトウェアの専門用語では、ここでは認証と承認のクロスカッティングの関心事について話しています。

• _認証_は、システム内で何かを行っているエンドユーザーが、システムが信じている人物であることを確認します。ここでは、Lokadは、認証が可能な限り_委任される_べきであるという現代的なアプローチを採用しています。エンドユーザーは、別のパスワードを扱う必要はありません。代わりに、Lokadは、認証を委任するための業界標準であるSAMLを利用しています。
• _承認_は、システム内で_誰が何をできるか_についての細かい制御を提供します。ここでは、Lokadは広範な正規ACL（アクセス制御リスト）システムを特徴としており、これは現代のエンタープライズシステムの_de facto_の実践です。Lokadはまた、ユーザーエクスペリエンスの観点からACLを補完するいくつかの個別化機能も備えています。

Lokadは、クライアントに最初に販売されたパッケージに関係なく、デフォルトですべてのセキュリティ機能を有効化します。ソフトウェアのベンダーにとって、オプションのセキュリティ⁴は非常に悪い慣行だと考えています。ソフトウェアのセキュリティを確保することは既に非常に困難です。このような慣行はそれをさらに悪化させるだけです。

公正を期すために、ACLの観点はおそらく_ソフトウェアセキュリティ_全体の最も難しい関心事ではないでしょう。もっと興味深い問題は、システムのアーキテクチャがどれだけ_設計段階でセキュリティ_を提供しているかです。ただし、この質問に答えることは、本記事の範囲を超えています。

Excelへのエクスポート

_Excelへのエクスポート_モジュールは、他のシステムでの使用や分析のためのデータの簡単な輸送方法を提供します。

Excelシートを作成するのは比較的簡単ですので、Lokadを含む多くのベンダーがこの領域での機能を提供しています。しかし、より詳細に調査すると、ほとんどのベンダーは半端な機能しか提供していないことがわかります。ここでは、_良い_エクスポートto-excelの実装の要点を見直してみましょう：

• 完全な履歴管理: システムは、これまでにエクスポートされたすべてのExcelシートを追跡して再ダウンロードすることができるようにする必要があります。実際には、スプレッドシート内の不正確な数字に直面することがあるため（不正確なデータ入力のためだけでなく）、このスプレッドシートを生成したコードパスの完全なトレースビリティがないと、問題のデバッグと修正の試みは非常に複雑化し、遅くなり - そして、場合によっては防止されるでしょう。
• スプレッドシートの能力を最大限に活用: プラクティショナーは、実際にはExcel自体の制限である100万行までの「肥満」スプレッドシートを生成できることを期待しています⁵。したがって、システムは、プラクティショナーが自分自身でなじみのあるツール内でデータの解析を行いたいだけである場合に、プラクティショナーの邪魔にならないような重いスプレッドシートを生成できる必要があります。もちろん、プラクティショナーは、その肥満なエクスポートが迅速であることも期待しています。
• スプレッドシート攻撃に対する組み込みの保護: Excelは大規模な組織にとって危険な攻撃ベクトルです。残念ながら、システムが生成するスプレッドシートのセキュリティを確保することは、後から考えることではなく、設計の一部である必要があります。ほぼDay 1からです。
• エクスポートのプログラム設定可能性: サプライチェーンのプラクティショナーにとって、APSとExcelの2つのソフトウェアを扱わなければならないことは十分に苦痛です。状況は、スプレッドシートが常にいくつかの追加の抽出後処理を必要とすることを要求しないように悪化すべきではありません。これは、すべてのことが抽出の前にAPS内で行われることを意味します。したがって、APSはエクスポート前にスプレッドシートを適切に準備するためのプログラムの機能を持つ必要があります。

Lokadは上記のすべてを提供していますが、競合他社のほとんどは提供していません。悪魔は細部に宿っています。

結論

私たちの確信は、Lokadが市場のほとんどのAPSよりも_シンプルな_ソフトウェアであるということです。それにもかかわらず、私たちの予測技術を通じたサプライチェーンのパフォーマンスを提供する能力はより大きいです。実際、APSの複雑さのほとんどは、内向きのソフトウェアの問題に直面して数十年前に行われたソフトウェア設計の選択に由来しています。ただし、一度行われたほとんどのアーキテクチャソフトウェアの選択は元に戻すことはできません。