量的サプライチェーンのイニシアチブ

量的サプライチェーン最適化、または短縮して量的サプライチェーンは、単純に言えば、現代のコンピューティングリソースの能力を活用した人間の知性を最大限に活用することを目指す、サプライチェーンに関する広範な視点です。しかし、この視点はすべてを網羅しているわけではありません。これはサプライチェーンの課題の最終的な解決策を提供するものではなく、状況を改善するためにほぼ常に使用できる補完的なアプローチであることを意味します。

イニシアチブ

量的サプライチェーンは、企業のサービス品質を向上させ、在庫の過剰や棄却を減らし、生産性を向上させ、購買価格と運営コストを低下させるなど、さまざまな利点をもたらします。サプライチェーンの課題は、さまざまな状況によって大きく異なるため、量的サプライチェーンはこの多様性を受け入れ、それに直面しながら努力します。ただし、サプライチェーンを最適化するためのより古典的なアプローチに慣れているサプライチェーンの専門家にとっては、量的サプライチェーンは少し戸惑うかもしれません。

以下では、サプライチェーンにおける量的な視点を最大限に活用するために必要な要素を見直し、明確化します。量的サプライチェーンのイニシアチブの目標と意図を検討し、実行に責任を持つチームの役割とスキルを確認します。最後に、量的サプライチェーンに関連する方法論の概要を説明します。

目標

小規模な企業を除いて、サプライチェーンは1日に何百万もの意思決定を行っています。在庫を保持するために、毎日、会社はそのユニットをそのままにしておくという決定を下しています。さらに、同じロジックは、生産または購入できる存在しない在庫ユニットにも適用されます。何もしないこと自体がすでに意思決定です。

量的サプライチェーンは、会社が毎日行う何百万、もしくは何十億もの意思決定を最適化することに関連しており、何百万、もしくは何十億もの意思決定を行う場合、コンピュータはこの取り組みで中心的な役割を果たします。これは驚くべきことではありません。なぜなら、サプライチェーンは、会計の後、1970年代後半にデジタル化された最初の企業機能の1つでした。しかし、量的サプライチェーンは、デジタル化をさらに進めることを目指しています。

ここで、過去20年間にわたって「将来のサプライチェーンシステム」を展開しようとする誤った試みが頻繁に行われてきたことを認めなければなりません。こうしたシステムは、サプライチェーンに混乱をもたらすだけでなく、ブラックボックス効果と誤った自動化を組み合わせ、人間の介入では問題を修正できないほど多くの誤った意思決定を生成しました。

ある程度まで、量的サプライチェーンはこれらのミスから生まれました。システムが自社の経営陣よりもビジネスをよりよく理解しているという幻想を抱くのではなく、経営陣が生成した洞察を実行することに焦点を当てる必要がありますが、信頼性、明確さ、機敏性を高める必要があります。ソフトウェア技術は有能なエンエーブラーですが、現在のソフトウェアの能力を考慮すると、人々を完全に解決策から排除することは現実的な選択肢ではありません。

この目標には、会社が製品、材料、その他のリソースを追跡するために使用するソフトウェアは、意思決定を最適化するために会社が必要とするソフトウェアとは異なることをすぐに理解する必要があります。実際、ERP、WMS、MRP、OMSなどのソフトウェアは、主に会社のプロセスとデータエントリの流れを操作することに焦点を当てています。誤解しないでください、データエントリの効率化とすべての事務作業の自動化には大きな利点があります。ただし、私たちのポイントは、これらのタスクがまったく課題に対処していないということです。つまり、会社の能力を向上させるためには、人間の洞察を実行する能力を高め、サプライチェーンが要求するスケールで実行する必要があるということです。

したがって、測定なしでは最適化はありません。したがって、数量的サプライチェーンは、その名前が示すように、測定に非常に関連しています。在庫の購入、在庫の移動などのサプライチェーンの意思決定には結果があり、そのような意思決定の品質は、健全なビジネスの視点で_財務的に_評価されるべきです（たとえば、ドルで）。ただし、良い、堅実なメトリックを持つには、かなりの努力が必要です。数量的サプライチェーンの目標の1つは、そのようなメトリックを確立する会社を支援することであり、これはプロジェクトの後の段階で非常に重要な役割を果たします。全体的なサプライチェーンのイニシアチブの投資回収率（ROI）を評価する際にも重要です。

最後に、前述のように、数量的サプライチェーンは包括的なパラダイムではありません。会社のサプライチェーンのすべてを修正または改善することを目指していません。信頼できるサプライヤーや信頼できる物流パートナーを見つけるのを手助けすることを約束しません。優れたチームを雇い、彼らの士気を高く保つのを手助けすることを約束しません。しかし、その非常に特定の焦点のおかげで、数量的サプライチェーンは具体的な結果を提供する能力を持っています。

プロジェクトの役割

数量的サプライチェーンは、規模の大きなサプライチェーンを扱う場合でも、驚くほど少ない人的リソースを必要とします。ただし、このようなイニシアチブには特定のリソースが必要です。このセクションでは、それらの詳細について説明します。ただし、異なる役割とそれらの特異性について詳しく説明する前に、まず、数量的サプライチェーンの1つの基本原則を紹介しましょう。それは、会社がすべての人間の介入を活用するべきだということです。

この原則は、従来のサプライチェーンソリューションでは起こらないことに反します。人間の努力はソリューションによって消費され、_活用_されません。絶え間ない意思決定の流れを維持するためには、絶え間ない手動のエントリが必要です。このようなエントリはさまざまな形で行われることがあります。季節プロファイルの調整、例外とアラートの処理、奇妙な予測値の修正などです。

数量的サプライチェーンは、この視点を逆転させることを目指しています。人的労働が高価であるだけでなく、サプライチェーンの専門知識と鋭いビジネスの洞察力は、繰り返しのタスクに浪費されるにはあまりにも希少で貴重です。手動介入の根本的な原因を修正する必要があります。予測値がオフであれば、値自体を修正する意味はありません。修正する必要があるのは、入力データまたは予測アルゴリズム自体です。症状を修正することは、同じ問題に対処し続けることを保証します。

数量的サプライチェーンのイニシアチブを実行するために必要なチームのサイズは、サプライチェーン自体の規模によって異なります。スペクトラムの下限では、年商2000万ドル以下の企業ではFTE（フルタイム従業員）未満で済むことがあります。スペクトラムの上限では、数十億ドルの在庫が通常関与しています。

サプライチェーンリーダー：数量的サプライチェーンはパラダイムの変更です。変化を推進するには、トップマネジメントからのリーダーシップとサポートが必要です。供給チェーンのリーダーシップは、ソリューションの「技術的な側面」と見なされるものにあまり直接関与する時間がないと感じることがあります。しかし、数量的サプライチェーンは、戦略的な洞察をスケールで実行することに関してです。イニシアチブを担当するチームと戦略的な洞察を共有しないことは、失敗のレシピです。マネジメントは、関連するメトリックとKPIをすべて提供することを期待されているわけではありません-これらをまとめるのに多くの努力がかかるためです-が、マネジメントはそれらに疑問を投げかけることが確かに期待されています。

サプライチェーンコーディネーター：数量的サプライチェーンイニシアチブ自体は非常にスタッフを削減することを意図していますが、ほとんどのサプライチェーンはそうではないか、少なくともそうではありません。全員を乗せることができないと、混乱が生じ、イニシアチブが遅れる可能性があります。したがって、コーディネーターのミッションは、イニシアチブに必要なすべての内部フィードバックを収集し、関係者とコミュニケーションを取ることです。コーディネーターは、行われる必要があるプロセスと意思決定を明確にし、それらの意思決定を最適化するために使用されるメトリックとKPIにフィードバックを得ます。また、ソリューションが会社のワークフローを受け入れる一方で、イニシアチブの後の段階でこれらのワークフローを見直す可能性を確保します。

データオフィサー：数量的サプライチェーンはデータに極めて依存しており、すべてのイニシアチブはバッチ処理の観点から信頼性のあるデータへのアクセスを持つ必要があります。実際、イニシアチブは単に会社のシステムの数行を読むだけではなく、販売履歴全体、購入履歴全体、製品カタログ全体などを読み込むことを含みます。データオフィサーは通常、イニシアチブをサポートするためにIT部門によって委任されます。彼はすべてのデータ抽出ロジックを自動化し、このロジックを日次抽出のスケジュールに組み込む責任を持ちます。実際、データオフィサーの取り組みは、イニシアチブの最初の段階で主に集中されます。

サプライチェーンサイエンティスト：彼はコーディネーターによって収集された洞察とデータオフィサーによって抽出されたデータを組み合わせるために技術を使用します-詳細は後述します-。サイエンティストは、データを準備することから始めます。これは驚くほど困難な作業であり、不確かな点がある場合には、最初にデータを作成した多くの人々とコーディネーターが対話して、不明な点を明確にする必要があります。彼は戦略を形式化し、例えば提案された再発注数量などの意思決定を生成するために使用できるようにします。最後に、サプライチェーンサイエンティストは、明確さ、透明性、および制御を確保するために、データパイプライン全体にダッシュボードとKPIを装備します。

中規模企業の場合、コーディネーターとデータオフィサーの役割を同じ人物が果たすことは非常に効率的です。ただし、このような人物が組織内に存在する場合でも、単一の従業員に見つけることが容易ではないスキルの範囲が必要です。ただし、イニシアチブが進行するにつれてコーディネーターが会社のデータベースに高いレベルの理解を持つことができれば、それは大きなプラスです。実際、ITの状況は常に変化しており、変化がイニシアチブにどのように影響するかを予測することは、スムーズな進行を確保するのに非常に役立ちます。

テクノロジー

これまで、数量的サプライチェーンをサポートするために必要なソフトウェアテクノロジーについてはあまり具体的に触れていませんでした。しかし、数量的サプライチェーンは、それを実装するために使用されるテクノロジースタックに極めて依存しています。概念的には、ソフトウェアの各部分をゼロから再実装することができますが、サプライチェーンサイエンティストは、イニシアチブの過程で提供できる範囲をはるかに超える予測や数値最適化などの特定の機能を必要とします。

数量的サプライチェーンの最初の要件は、プログラム可能な機能を備えたデータプラットフォームです。自然に、サプライチェーンデータとサプライチェンの問題を扱うために特別に設計されたデータプラットフォームにアクセスできることは、確かな利点です。デスクトップワークステーションは現在、複数のテラバイトを保存できるようになっていますが、それはイニシアチブを実行するために他の望ましい特性を提供することを意味するわけではありません。例えば、ハードウェアの障害に対する信頼性、すべてのアクセスの監査可能性、データのエクスポートとの互換性などです。さらに、サプライチェンのデータセットは大きい傾向があるため、データプラットフォームはよりスケーラブルであり、つまり短時間で大量のデータを処理できる能力を持っている必要があります。

データプラットフォームには、プログラム可能な機能が必要です。これは、ほぼ任意のデータ処理ロジックを実装して実行する可能性を指します。このような機能は、プログラミング言語を通じて提供されます。プログラミングは非常に技術的なスキルとして正しく認識されており、多くのベンダーが「プログラミング」を必要とするソリューションに対して、ボタンやメニューを持つシンプルなユーザーインターフェースをユーザーに提供するために恐怖心を利用しています。しかし、サプライチェンチームがプログラム可能な機能を拒否されると、Excelシートが引き継ぎます。なぜなら、Excelは任意に複雑な数式を書くことができるプログラム可能な機能を提供しているからです。プログラム可能な機能は、単なるガジェットではなく、核心要件です。

最後に、サプライチェンに特化したデータプラットフォームを持つことには、重要な利点があります。実際、ある種のデータプラットフォームの必要性は、サプライチェンに特有ではありません。銀行やファンドによって行われる量的取引も同様のニーズを持っています。ただし、サプライチェンの意思決定には、高頻度取引のようなサブミリ秒のレイテンシは必要ありません。データプラットフォームの設計は、エンジニアリングのトレードオフとソフトウェアエコシステムの問題であり、サプライチェンの課題自体と一致している必要があります。

数量的サプライチェンの2番目の要件は、**確率的な予測エンジンです。**このソフトウェアは、すべての可能な未来に確率を割り当てる責任を持っています。このタイプの予測は最初は少し驚くかもしれませんが、それは未来を予測するという直感に反するものです。実際のところ、「キャッチ」は不確実性にあります。未来は確定的ではなく、単一の予測は間違っていることが保証されています。古典的な予測の視点では、不確実性や変動性を否定し、結果として、正確であるはずの予測に苦しむことになります。確率的な予測エンジンは、この問題に確率を使って直接対処します。

サプライチェーンにおける確率的な予測は、通常、リードタイムの予測から始まり、需要予測に続きます。リードタイムの予測は確率的な予測であり、すべての可能なリードタイムの期間に確率が割り当てられます。通常、日単位で表されます。次に、需要予測も確率的な予測であり、この予測は入力として提供されたリードタイムの予測の上に構築されます。このようにして、需要予測がカバーするべき期間は、それ自体が不確定なリードタイムに一致する必要があります。

確率的な予測エンジンが確率分布のセットを提供するため、その予測の出力には通常の予測エンジンの出力よりもはるかに多くのデータが含まれます。これ自体はブロッキングの問題ではありませんが、膨大な数の確率を処理する際に摩擦が生じるのを避けるためには、データプラットフォームと予測エンジンの間で高度な協力が必要です。

プロジェクトのフェーズ

数量的サプライチェーンは、ソフトウェアエンジニアリングのR&Dとデータサイエンスで知られるベストプラクティスに強く影響を受けています。この方法論は、事前の仕様にはあまり重点を置かず、アジリティと予期しない問題や結果からの回復能力に重点を置いています。その結果、この方法論は、ソフトウェア業界に深く関与していない企業にとってはかなり驚くべきものとして認識される傾向があります。

最初のフェーズはスコープフェーズであり、イニシアチブでカバーする予定のサプライチェンの意思決定を定義します。このフェーズでは、意思決定プロセスと関連するデータの予想される複雑さを診断するためにも使用されます。

2番目のフェーズはデータ準備フェーズです。これには、関連するデータを会社のシステムから別の分析プラットフォームに自動的にコピーするためのセットアップの確立が含まれます。また、このデータを数量的分析のために準備することも含まれます。

3番目のフェーズはパイロットフェーズであり、会社の以前のプロセスを既に上回る、例えば提案された購入数量などの意思決定ロジックを実装することから成り立ちます。このロジックは完全に自動化されることが期待されています。

4番目のフェーズは本番フェーズであり、イニシアチブを安定速度に導き、パフォーマンスを監視および維持し、サプライチェンモデル自体の望ましい精度の合意が達成されるフェーズです。

スコープフェーズは最も直接的なフェーズであり、数量的サプライチェーンイニシアチブがカバーするルーチンの意思決定を特定します。これらの意思決定には多くの制約が関与する場合があります：MOQ（最小発注数量）、フルコンテナ、最大倉庫容量など、これらの制約は注意深く検討する必要があります。次に、意思決定には経済的な要素も関連しています：保有コスト、欠品コスト、粗利益など、このような経済的要素も研究する必要があります。最後に、関連する過去のデータとデータが抽出されるシステムも特定する必要があります。

データ準備フェーズは最も困難なフェーズです。ほとんどの失敗はこの段階で起こりがちです。データにアクセスし、データを理解することは、ほとんど常に過小評価される課題です。運用システム（例：ERP / MRP / WMS / OMS）は、会社を運営し、会社を稼働させるために設計されています。過去のデータは、データの記録が最初の目的ではなかったため、そのようなシステムの副産物です。したがって、このフェーズでは多くの困難が予想されます。困難に直面した場合、ほとんどの企業は不幸な反射を示します：後退して完全な仕様を書き出しましょう。残念ながら、仕様は既知または予想される困難しかカバーできません。しかし、このフェーズで遭遇するほとんどの重要な問題は、計画することができない要素です。

実際にデータをテストしてデータ駆動の意思決定を生成すると、問題は実際にのみ明らかになる傾向があります。ロジックが正当と考えられるにもかかわらず、意思決定が間違って出る場合、おそらくデータに問題があるでしょう。データ駆動の意思決定は、データの問題に対して多少敏感であり、したがって、会社が自社のデータにどれだけの制御を持っているかを問う優れた方法です。さらに、このプロセスは、会社にとって意味のある方法でデータを問いかけます。データの品質とデータの理解は、単なる手段に過ぎません：会社にとって価値のあるものを提供するための手段です。データ駆動の意思決定に重要な影響を与えるデータの問題に努力を集中することは非常に合理的です。

パイロットフェーズはサプライチェーン管理をテストするフェーズです。確率的な予測で不確実性を受け入れることは、かなり直感に反するかもしれません。同時に、週次または月次の予測、安全在庫、在庫カバー、在庫アラート、ABC分析など、多くの伝統的な手法は実際には害をもたらすことがあります。これは、数量的サプライチェーンイニシアチブが自由に動くべきではないことを意味するものではありません。実際、数量的サプライチェーンは測定可能なパフォーマンスに関するものです。ただし、多くの伝統的なサプライチェーンの手法は、問題を解決するための方法とは逆の方法で問題をフレーム化する傾向があります。したがって、パイロットフェーズでは、サプライチェーンのリーダーシップにとっての主要な課題は、心を開いたままであり、後の段階で非効率を生み出す要素をイニシアチブに再注入しないことです。結果を呪いながら原因を大切にすることはできません。

その後、サプライチェーンの科学者と技術は、比較的短期間で意思決定を生成するために実装するためのロジックがテストされます。最初の目標は、実践者が合理的な決定と認識するもの、つまり手動の修正を必要としない決定を生成することです。自動化された「正当な」決定を生成することがどれほど大きな課題であるかを過小評価しないことをお勧めします。従来のサプライチェーンシステムは、運用するために多くの手動修正が必要です：新製品、プロモーション、在庫切れなど…量的サプライチェーンは新しいルールを確立します：日常的な操作には手動の入力は許可されず、すべての要素はロジックに組み込まれるべきです。

サプライチェーンコーディネーターは、意思決定ロジックに統合する必要があるすべての要素、ワークフロー、特異性を収集するために存在しています。その後、サプライチェーンの科学者は、意思決定に関連する最初の一連のKPIを実装します。これらのKPIは、高度な数値メソッドが使用される際に生じるブラックボックス効果を回避するために導入されます。重要なことは、KPIはサプライチェーンリーダーと共に考案され、測定が会社の戦略と一致していることを確認する彼が担当していることです。

生産フェーズでは、イニシアチブを安定化させ、クルーズスピードにまで持っていきます。ロジックによって生成された意思決定は積極的に使用され、関連する結果が密に監視されます。リードタイムのため、任意のサプライチェーンの意思決定の影響を評価するには数週間から数か月かかることが一般的です。したがって、生産フェーズでのイニシアチブのペースは遅くなり、自動化された意思決定のパフォーマンスについて信頼性のある評価が可能になるようになります。イニシアチブは継続的な改善フェーズに入ります。さらなる改善は常に望ましいですが、ロジックの改善の利点とそれらの改善の複雑さとの間にはバランスが取られなければなりません。これにより、ソリューション全体の保守性を維持するために必要なバランスが取れます。

日常的なデータ入力作業から解放されたサプライチェーンコーディネーターは、サプライチェーン管理が提案する戦略的な洞察に焦点を当てることができます。通常、パイロットフェーズ中に特定された望ましいサプライチェーンプロセスの変更は、一度にすべてを変更することで運用を混乱させることを避けるために保留にされています。しかし、意思決定ロジックの変化のペースが遅くなったため、プロセスを段階的に見直し、より良いルーチンの意思決定以上のパフォーマンス向上を実現することが可能になります。

サプライチェーンの科学者は、KPIとデータ品質にますます重点を置きながらロジックを微調整し続けます。また、時間の経過とともに、稀な状況に関連する微妙な欠陥や制約が明らかになるため、ロジックの見直しも彼の責任です。その後、プロセスが変更されると、意思決定ロジックも見直され、ワークフローと戦略と完全に一致するようになります。また、内部プロセスが変更されない場合でも、一般的なITおよびビジネス環境は常に変化し続けます。サプライチェーンの科学者は、この常に変化する状態の中で意思決定ロジックが最新であることを確認する必要があります。

成果物

量的サプライチェーンの目標は、実行可能な意思決定を提供することです-購買注文の推奨数量が典型的な例です。以下では、これらの意思決定の具体的な形式と配信メカニズムをさらに明確に説明します。成果物の期待値を明確に設定することは、量的サプライチェーンが表す旅の重要なステップです。また、最適化された数値結果だけが望ましい出力ではありません。データの健康監視や管理のKPIなど、他のいくつかの出力も成果物に含まれるべきです。実際には、量的サプライチェーンイニシアチブの成果物は、イニシアチブ自体をサポートするために使用されるソフトウェアソリューションの柔軟性に依存します。それにもかかわらず、それらは使用されている技術に関係なく、その_意図_によって主に定義されます。

成果物としてのスクリプト

量的サプライチェーンは、完全に自動化されたデータパイプラインを重視しています。これは、ソフトウェアのセットアップが自律的に実行されることを意味するものではありません。大規模なサプライチェーンが考慮される場合、高度な監視が必要です。ただし、データパイプラインは、パイプライン内の個々のステップが実際には手動操作に依存しないという意味で、完全に自動化されていることが期待されます。実際には、マニュアル操作がサプライチェーンデータ処理をサポートするために関与する場合、ソリューションは実際にはスケーリングされません。

量的サプライチェーンのこの洞察の直接的な結果として、量的サプライチェーンの取り組みの成果物は、必ずしもソフトウェアの全体的な再実装を期待しているわけではありません。量的サプライチェーンに特化したソフトウェアソリューションは、サプライチェーンの課題に厳密に焦点を当てることができます。クラウドコンピューティングプラットフォーム内で自動割り当てられる分散コンピューティングリソースを活用するなどの低レベルの技術的な詳細は、抽象化されることが期待されます。チームは、そのような問題に深入りする必要はありません。なぜなら、それらの側面はツール自体によって適切に管理されることが期待されるからです。

成果物は、サプライチェーンの要件を満たすことができるプログラミング言語で通常書かれたスクリプトとして具現化されます。ここでは「スクリプト」という用語を使用していますが、「ソースコード」という用語と密接に関連しています。スクリプトは、高度な抽象化とタスク自体への焦点を強調する一方、ソースコードは、コンピューティングハードウェア自体の正確な反映を意図した低レベルの視点を強調します。量的サプライチェーンにとって重要なのは、明らかにサプライチェンの視点であり、計算ハードウェアは二次的な重要性の技術的な側面です。

過去10年間、エンドカスタマーアプリケーションのWYSIWYG（what-you-see-is-what-you-get）ユーザーインターフェースの成功により、多くのサプライチェーンソフトウェアベンダーが、サプライチェーンの計画と最適化のためのWYSIWYGソリューションを模倣しようとしました。しかし、この種のインターフェースのほぼシステマチックな失敗から得られる教訓は、サプライチェーンが複雑であり、プログラムツールの必要性を回避することはできないということです。私たちの経験から、ドラッグアンドドロップツールが、例えば重なり合う最小発注数量（MOQ）などの複雑な非線形性を適切に反映できると期待することは、最善の場合でも幻想的です。ツール内でサプライチェンの課題を表現するためには、プログラムの表現力が必要です。

当然ながら、エンドユーザーの視点からは、スクリプトは量的サプライチェーンの担当者が量的サプライチェーンの取り組みの具体的な成果物として期待するものではありません。人々は、統合されたKPIと意思決定の提案をまとめたダッシュボードと対話します。ただし、これらのダッシュボードは一時的で使い捨てです。それらは単に関連するサプライチェーンデータの上でスクリプトを再実行することで得られます。この区別は少し微妙ですが、実際の成果物であるスクリプトと、数値表現であるエンドユーザーが通常見ることができるものとを混同しないようにすることが重要です。

データの健康ダッシュボード

サプライチェーンの最適な意思決定を提供する前に、量的サプライチェーンの取り組みをサポートするシステムで処理されるデータが数値的にも意味的にも正しいことを確認する必要があります。データの健康モニタリングダッシュボード、または単に「データの健康ダッシュボード」と呼ばれるものは、解決策によって返されるすべての数値結果の精度のために、データの正確性に対する高い信頼度を確保することを目的としています。これらのダッシュボードはまた、既存のデータの品質を向上させるためにサプライチェーンチームを支援します。

数値エラーは明らかです。ERPからエクスポートされたCSVファイルによれば、製品ABCの在庫は42個ですが、ERPのWebコンソールでは在庫が13個しか報告されていません。ここでは、同じであるべき場所で異なる数値があることが明らかです。データの健康ダッシュボードは、データの集計が予想される数値範囲内に収まっているかどうかを単純にチェックすることで、これらの比較的明白な問題に対処します。

意味エラーはより微妙であり、実際には特定するのがはるかに困難です。データの準備中に行われる作業のほとんどは、実際にはすべての意味エラーを特定し修正することです。例えば、ERPのフィールドstockinvは「在庫」として文書化されているかもしれません。したがって、サプライチェーンチームは、この数量が負になることはありえないと想定しています。なぜなら、明らかに、これらのユニットが棚に物理的に手の届く範囲内にある場合、正の数量でなければならないからです。しかし、ERPのドキュメントはわずかに誤解を招く可能性もあり、この数量は「在庫あり」という名前の方が適切であったかもしれません。なぜなら、在庫切れが発生し、クライアントがバックオーダーを発行した場合、数量は負になり、すでにクライアントに対して一定数のユニットが発注されていることを反映するためです。この場合、意味エラーが示されています。数値自体は間違っているわけではありませんが、数値の理解がおおよそのものです。実際には、意味的な近似は多くの一貫性のない動作を生成し、それによってサプライチェーン内で継続的な摩擦コストが発生します。

データの健康ダッシュボードは、会社がデータを十分に信頼できるかどうかを即座に検査することによって、データが十分に良好であるかどうかを判断するための数値を統合します。実際には、このソリューションは日常的な生産目的で使用されるため、重要なデータの問題が近くの検査を通じて特定される必要があります。そうでない場合、サプライチェーンは誤ったデータの上で数日、数週間にわたって運用される可能性があります。この点で、データの健康ダッシュボードは信号機に似ています。緑なら進む、赤なら停止です。

さらに、規模の大きなサプライチェーンを考慮すると、通常、破損したデータや他の間違ったデータが一定量存在します。このデータは、誤った手入力や会社システム自体のまれなエッジケースによって生じます。実際には、規模の大きなサプライチェーンでは、サプライチェーンデータが100％正確であることを期待することは合理的ではありません。代わりに、これらのエラーによって生成される摩擦コストがほぼ無視できるほどデータが正確であることを確認する必要があります。

したがって、データの健康ダッシュボードは、特定のデータエラーに関する統計を収集することも期待されています。これらの統計は、データを信頼できるものとするために重要です。そのためには、サプライチェーンの科学者が頻繁に呼び出され、適切に選ばれたアラートの閾値を設定し、通常はソリューションの強制停止と関連付けられます。閾値の設定には注意が必要です。閾値が低すぎると、ソリューションは使用できなくなり、「特定のデータの問題」として頻繁に停止します。しかし、閾値が高すぎると、データエラーによって生成される摩擦コストが大きくなり、イニシアチブ自体がもたらす利点を損なう可能性があります。

赤緑信号の表示を超えて、データの健康ダッシュボードはデータ改善の取り組みに優先順位付けされた洞察を提供することも意図されています。実際、多くのデータポイントは間違っているかもしれませんが、重要ではありません。例えば、市場の需要が数年前に消えた場合、製品の購入価格が間違っていても問題ありません。この製品に対しては、これ以上の発注はありません。

量的サプライチェーンでは、データエラーの財務への影響と修正に関連する労働コストに対する見積もりに対して、データエラーの詳細な解像度が優先されるべきであると強調しています。実際、状況によっては、単一の誤ったデータポイントの修正に関連するコストは非常に異なるため、提案された優先順位付けに考慮する必要があります。最終的に、修正のコストがエラーによって生成されるサプライチェーンコストよりも高いと判断された場合、データ改善プロセスは停止することができます。

優先順位付けされた意思決定ダッシュボード

これまで見てきたように、量的サプライチェーンの意思決定は、真の定量的な視点から評価されることができます。したがって、量的サプライチェーンの取り組みの主要な運用成果物の1つは、データパイプラインの最終的な数値結果として得られた意思決定をまとめたダッシュボードです。このようなダッシュボードは、各製品ごとに即座に再注文するための正確な数量をリストアップするだけの単純なテーブルとして構成されることがあります。MOQ（最小注文数量）やその他の注文制約が存在する場合は、適切な閾値が満たされるまで、提案される数量はほとんどゼロになることがあります。

簡単のために、ここではこれらの数値結果がダッシュボードにまとめられると仮定していますが、ダッシュボード自体は関連性があるかどうかは別として、ユーザーインターフェースの特定の形式です。実際には、量的サプライチェーンの取り組みを支えるソフトウェアは、プログラム的に柔軟であり、さまざまなデータ形式でこれらの結果をパッケージ化するための多くの方法を提供することが期待されています。たとえば、数値結果はフラットテキストファイルにまとめられ、会社の資産を管理するために自動的にインポートされることを意図しています。

決定の形式は、対象となるサプライチェーンのタスクに大きく依存しますが、ほとんどのタスクではこれらの決定を優先順位付けする必要があります。たとえば、発注のための提案数量を計算する行為は、取得する単位の優先順位付けリストを通じて分解することができます。最も利益の高い単位が最初にランク付けされます。在庫は収益の減少につながるため、同じ製品に対して2番目の単位を取得することは、市場の需要の減少分のみを対処することになります。したがって、この製品の2番目の単位は、全体のリストの2番目のエントリではないかもしれません。代わりに、2番目に利益の高い単位は他の製品に関連付けられることがあります。取得する単位の優先順位付けリストは、概念的には終わりがありません。常に1つの単位を購入することができます。市場の需要は有限ですので、購入したすべての単位はある時点で不良在庫になります。この優先順位付けリストを購入の最終数量に変換するには、_停止基準_を導入し、製品ごとの数量を合計するだけです。実際には、非線形の注文制約がこのタスクをさらに複雑にしますが、簡単のために、この段階ではこれらの制約を一旦置いておきます。

量的サプライチェーンの観点から、意思決定の優先順位付けは非常に自然な操作です。すべての意思決定はドルで表される財務的な結果と関連付けられているため、最も利益の高いものから最も利益の低いものまでの順位付けは簡単です。したがって、提案されるサプライチェーンの意思決定をまとめる多くのダッシュボードは、実際には優先順位付けされた意思決定のリストとして期待されることがあります。これらのダッシュボードには、上位に高い利益をもたらす意思決定がリストアップされ、下位に非常に利益の低いものがリストアップされています。また、サプライチェーンの実践者は、意思決定が利益をもたらさない場合にはリストを切り捨てることも決めるかもしれません。ただし、明らかに利益をもたらさないエントリに対して行動を起こすことは期待されていないにしても、利益のしきい値の下にある意思決定を検査できることから得られる洞察がしばしばあります。

このような意思決定に基づくダッシュボードを提供するためには、量的サプライチェーンをサポートするソフトウェアソリューションが、可能な意思決定の膨大な量を数値的に探索できる必要があります。たとえば、ソリューションは、各製品の各場所で、単位ごとに単位ごとに購入することの財務的な影響を考慮することができる必要があります。予想されるように、この操作にはかなりの計算リソースが必要になる場合があります。幸いなことに、現在では、コンピューティングハードウェアは最大のグローバルサプライチェーンにさえ対応できる能力を持っています。量的サプライチェーンの基盤となるソフトウェアソリューションが適切に設計されている場合、データ処理のスケーラビリティはサプライチェーンチームにとって問題ではありません。

数値結果のホワイトボックス化

サプライチェーンや他の分野でも蔑まれるように「ブラックボックス」と呼ばれるシステムは、そのシステムと対話する実践者によって説明できない出力を生成するシステムです。量的サプライチェーンは、自動化されたデータパイプラインに特化しているため、「ブラックボックス」として供給チェーンチームが分類するものを提供するリスクにも直面しています。実際、サプライチェーンの意思決定の財務的な影響は企業にとって非常に重要であり、新しいシステムが状況を改善する一方で、災害を引き起こす可能性もあります。自動化は非常に望ましいですが、それは供給チェーンチームが量的サプライチェーンイニシアチブをサポートするデータパイプラインによって提供されるものを徹底的に理解することを期待されていないことを意味しません。

「ホワイトボックス化」という用語は、供給チェーンチームの利益のためにソリューションを完全に透明にするために必要な取り組みを指します。このアプローチは、技術が設計上透明であるわけではないことを強調しています。透明性は、イニシアチブそのものの一部である特定の取り組みの結果です。単純な線形回帰でも、実際には驚くべき結果を生成することがあります。例外的な個人を除いて、ほとんどの人は、4つ以上の次元が関与する場合、線形モデルの「予想される」出力に対して直感的な理解を持っていません。しかし、サプライチェーンの問題はしばしば数十、場合によっては数百の変数を含みます。したがって、単純な統計モデルでさえ、供給チェーンの実践者にとっては事実上のブラックボックスです。量的サプライチェーンで推奨されるように機械学習アルゴリズムが使用される場合、実践者はさらに暗闇に置かれます。

ブラックボックス効果は実際の問題ですが、現実的な解決策は、人間の心に直感的に理解できる計算にデータ処理を単純化することにはありません。このアプローチは、現代のコンピューティングリソースの利点を完全に破壊する極度の非効率性のレシピです。プロセスを単純化することは答えではありません。ホワイトボックス化こそが答えです。

最も複雑なサプライチェーンの推奨事項でも、サプライチェーンの実践者に対しては、推奨されるサプライチェーンの意思決定に対して透明性を持たせることができます。これは、推奨される購買注文として単に製品と数量の2つの列を表示するだけでなく、意思決定を支援するいくつかの列を含むテーブルを表示することによって実現できます。これらの追加の列には、現在の在庫、過去1か月間の総需要、予想されるリードタイム、在庫切れの予想される財務的なコスト（注文が行われない場合）、過剰在庫の予想される財務的なコスト（推奨される注文に関連するリスク）などが含まれます。これらの列は、サプライチェーンチームに推奨される数量の簡単な検証を提供するために作成されています。列を通じて、チームは数値の出力に対して迅速に信頼を築くことができ、さらなる改善が必要なソリューションの弱点も特定することができます。

ホワイトボックス化の目的でダッシュボードを拡張することは、ある意味で芸術の一部です。数百万の数値を生成することは簡単ですが、スマートフォンで利用可能な計算リソース以上のものはありません。しかし、毎日見る価値のある10個の数値を生成することは非常に困難です。したがって、核心的な課題は、推奨されるサプライチェーンの意思決定に光を当てるのに十分な数のKPI（重要業績評価指標）を特定することです。良いKPIは通常、多くの作業を必要とします。通常、サプライチェーンでは誤解を招く傾向がある単純な定義ではありません。たとえば、「単位購入価格」という単純な列でさえも、サプライヤーが数量割引を提供する場合、購入価格が数量に依存するため、非常に誤解を招くことがあります。

戦略的なダッシュボード

小規模な意思決定に焦点を当てることは必要ですが、それは定量的なパフォーマンス評価に適したアプローチの一つです。サプライチェーンは、パフォーマンスを次のレベルに引き上げるために、より大きく、より破壊的な方法で調整する必要がある場合もあります。たとえば、より適切に選ばれた在庫の単位を購入することは、サービスレベルをわずかに向上させます。しかし、ある時点で倉庫はいっぱいになり、追加の単位を購入することはできません。この状況では、より大きな倉庫を検討する必要があります。この制約の解除の影響を評価するために、倉庫容量の制約を計算から除外し、任意の大きな倉庫での運営の全体的な財務的なメリットを評価することができます。サプライチェーン管理は、倉庫容量自体によって課せられる摩擦コストに関連する財務指標に注意を払い、いつ倉庫容量を増やすかを決定することができます。

通常、サプライチェーンは、日々の基準を見直すことができない多くの制約に基づいて運営されます。これらの制約には、運転資本、倉庫容量、輸送遅延、生産スループットなどが含まれます。各制約は、サプライチェーンにとって暗黙の機会費用と関連付けられており、通常は在庫の増加、遅延の増加、在庫切れの増加などに変換されます。機会費用は、制約自体を除去または弱体化させることによって得られるパフォーマンスの向上によって評価することができます。これらのシミュレーションのうちいくつかは実装が困難であることがわかるかもしれませんが、頻繁には、通常の意思決定、つまり発注数量の確立よりも困難ではありません。

量的サプライチェーンでは、これらの制約に関連する機会費用は、生産データパイプラインの一部であり、通常は専用のダッシュボードで具現化されるべきです。これらのダッシュボードは、サプライチェーン管理がサプライチェーンに大きな変化をもたらす時期を決定するのに役立つように特別に設計されています。このタイプのダッシュボードは戦略的なダッシュボードと呼ばれます。このアプローチは、サプライチェーンが運用上の制限に達しようとしていると感じたときに_ad hoc_なイニシアチブを強調する従来のサプライチェーンの実践とは異なり、戦略的ダッシュボードが毎日、または必要に応じてより頻繁に更新されるため、最後の瞬間の最後の努力をする必要はありません。それらは最新であり、長期的なイニシアチブから得られた洞察を活用する準備ができています。

戦略的なダッシュボードは、サプライチェーン管理の意思決定プロセスをサポートします。データパイプラインの一部であるため、市場が通常よりも速いペースで進化し始めると、KPIは会社の現状について最新の情報を提供し続けます。このアプローチは、既に遅れている問題にさらなる遅延を加える従来の_ad hoc_な調査に関連する伝統的な落とし穴を回避します。このアプローチはまた、利益を生まないことが判明する急いで行われた戦略的な意思決定という代替問題を大幅に軽減します。このような状況は最初から予測できる遺憾な状態です。

インスペクターダッシュボード

サプライチェーンは複雑で不安定です。これらの特性は、データパイプラインのデバッグを非常に困難なタスクにします。それにもかかわらず、このデータパイプラインは量的サプライチェーンイニシアチブの脊髄です。データ処理のミスやバグは、データパイプラインのどこでも発生する可能性があります。さらに悪いことに、最も頻繁な問題のタイプは「間違った数式」ではなく、「曖昧な意味」です。たとえば、パイプラインの初めでは、変数stockinvは在庫が利用可能であることを示しているかもしれません（負の値も可能です）。しかし、後で同じ変数が在庫が手元にあることを示すために使用される場合（値が正であることが期待されます）。変数stockinvの曖昧な解釈は、システムのクラッシュ（明らかであり、したがって比較的有害）からサプライチェーンの意思決定の沈黙的かつ普遍的な破壊に至るまで、さまざまな種類の誤った動作を引き起こす可能性があります。

供給チェーンは、長年にわたって設定されたさまざまなソフトウェアソリューションのユニークな組み合わせで構築されるため、「証明済み」のバグのないソフトウェアソリューションにアクセスすることは望めません。実際、ほとんどの問題はシステムの境界で発生します。異なるシステムからのデータを調整する場合や、同じシステム内の異なるモジュールからのデータを調整する場合に問題が発生します。したがって、ソフトウェアソリューションがどれだけ証明されているかに関係なく、ツールはデバッグプロセスを手軽にサポートできる必要があります。なぜなら、この種の問題は必ず発生するからです。

インスペクターダッシュボードの目的は、供給チェーンデータセットの詳細な表示を提供することです。ただし、これらのダッシュボードは、入力データテーブルを検査するための単純なドリルダウンではありません。このようなデータのスライスやダイスのアプローチは、本質を見失ってしまいます。供給チェーンは、物資の流れ、支払いの流れなどに関連しています。最も深刻なデータの問題のいくつかは、流れの連続性が「論理的に」失われたときに発生します。たとえば、倉庫Aから倉庫Bに商品を移動する際、倉庫Bのデータベースにはいくつかの商品エントリが欠落している場合があります。その結果、倉庫Aからのユニットが適切に製品に関連付けられずに倉庫Bに受け取られることで、微妙なデータの破損が発生します。数値の結果が奇妙に感じられる場合、インスペクターダッシュボードは供給チェーンの科学者が迅速なサンプルデータの調査を行うための選択肢です。

実際には、インスペクターダッシュボードは、製品コードやSKUなどの低レベルのエントリーポイントを提供し、このエントリーポイントに関連するすべてのデータを1つのビューにまとめます。航空宇宙の供給チェーンなど、多くの場所を通過する商品が流れる場合、インスペクターダッシュボードは通常、商品の軌跡を再構築しようとします。これらの商品は、複数の物理的な場所だけでなく、複数のシステムを経由しても移動する可能性があります。これらのデータを1つの場所に集めることで、供給チェーンの科学者はデータが意味をなしているかどうかを評価できます。出荷されている商品の出荷元を特定することは可能ですか？在庫の移動は公式の供給チェーンポリシーに合っていますか？インスペクターダッシュボードは「デバッグ」ツールです。ITの観点ではなく、供給チェーンの観点から、密接に結びついているデータをまとめるために設計されています。

インスペクターダッシュボードは、データヘルスダッシュボードの低レベルの相当です。データヘルスダッシュボードは通常、データに対してより高レベルの立場を取ります。また、インスペクターダッシュボードは通常、ホワイトボックス化の取り組みの一部です。供給チェーンの実践者が理解しがたい推奨事項に直面した場合、SKUや製品を詳しく調べる必要があります。そのため、インスペクターダッシュボードは、最終的な推奨事項の計算に寄与する多くの中間結果を含めるように調整されています。

成功の評価

数値的な方法と測定に重点を置いているにもかかわらず、私たちの経験からは、メトリクスはしばしばイニシアチブが正しい方向に進んでいるかどうかについて、あまりにも少なく、そしてしばしば遅すぎるということがわかっています。ほとんどのメトリクスは操作可能であり、これは通常、選択したアプローチの持続可能性に対する犠牲となります。したがって、Quantitative Supply Chainは明らかな改善を求めます。改善が微妙すぎてそれを検出するために高度な測定が必要な場合、そのイニシアチブはおそらく努力に値しなかったと考えられ、失敗と見なすべきです。逆に、改善が多くのメトリクスで顕著で一貫しており、供給チェーン全体がこれまで以上にアジャイルで反応性があると感じられる場合、そのイニシアチブはおそらく成功していると考えられます。

メトリクスは操作可能です

エンジニアがメトリクスに基づいて評価されることはほとんどないのは理由があります。彼らはメトリクスを利用して自分たちの利益になるように利用することができるため、会社の利益に奉仕するのではなく、メトリクスを利用することが非常に得意です。サプライチェーンは複雑であり、ほとんどの単純なメトリクスは、会社にとって徹底的に破壊的な方法で利用される可能性があります。この問題は、メトリクスに潜む抜け穴を閉じるだけの問題ではないと感じるかもしれません。しかし、私たちの経験からは、常にさらなる抜け穴が見つかるということが示されています。

メトリクスの逆算の物語

仮想の電子商取引を例に取りましょう。経営陣は、サービスレベルを改善する必要があると判断し、サービスレベルが主要なメトリクスとなります。サプライチェーンチームはこのメトリクスに従って作業を開始し、会社に莫大なコストをかけることになる在庫レベルを大幅に増やすという解決策を提案します。

その結果、経営陣はルールを変更し、在庫の最大量が定義され、チームはこの制限内で運営する必要があります。チームは数値を見直し、在庫レベルを下げる最も簡単な方法は、「不良品」として大量の在庫をフラグ付けし、積極的なプロモーションを引き起こすことです。在庫レベルは確かに下がりますが、粗利益も大幅に減少します。

問題は再び見逃されず、ルールが再度変更されます。在庫としてマークされることができる在庫の量に新しい制限が導入されます。この新しいルールを実施することは多大な努力を必要とします。なぜなら、サプライチェーンは突然「古い」在庫に苦しむことになり、大幅に割引する必要があるからです。この新しいルールに対応するために、チームは航空輸送の割合を海上輸送に比べて増やします。リードタイムが短縮され、在庫が減少しますが、運営コストは急速に上昇しています。

コントロールを失いつつある運営コストに対処するために、経営陣は再びルールを変更し、航空輸送で輸送できる商品の割合に上限を設けます。再び、新しいルールは混乱を引き起こします。なぜなら、これにより在庫切れが連鎖的に発生し、航空輸送を利用すれば防ぐことができた在庫切れが発生するからです。ますます厳しい制約の下で運営することを強いられる結果、チームはサプライヤーが提供する価格の割引を活用することを諦め始めます。少量の購入はリードタイムを短縮する方法の一つでもあります。しかし、再び、粗利益は減少します。

管理陣にとって、購入価格を元に戻すことははるかに難しい目標となります。この課題に対処するためには、単純なルールでは対応できず、代わりに各製品サブカテゴリーに対して多くの価格目標が導入されます。多くの目標が現実的ではなく、ミスを引き起こします。全体として、サプライチェーンの状況はますます明確ではありません。多くの側面からの圧力を受けて、サプライチェーンチームは需要計画プロセスのあいまいな機能である「製品の代替リスト」を調整し始めます。

実際に、管理陣はプロセスの早い段階で、一部の在庫切れが他のものほど影響がないことに気付きました。なぜなら、欠品している製品のいくつかには、ほぼ完璧な代替品が複数存在していたからです。そのため、全体的なサービスレベルを計算する際には、これらの製品の在庫切れは大幅に割り引かれることになりました。しかし、現在は非常なプレッシャーの下で運営されているサプライチェーンチームは、このリストの目的を元の意図から1〜2段階引き伸ばし始めています。似ていない製品もほぼ完璧な代替品としてリストに掲載されるようになりました。サービスレベルの指標は改善されますが、ビジネスは改善されません。

成功の落とし穴

メトリクスは操作される可能性があり、チームに有害なインセンティブが与えられると、メトリクスは誤解を招くように利用されることが多いです。しかし、状況は思われるほど悪くありません。実際に、私たちの経験からは、本当に機能不全のある企業文化以外では、従業員は一般的に自分の仕事を妨害する傾向はありません。むしろ、多くの従業員が、会社のポリシーを少し伸ばす必要があるとしても、正しいことをすることに誇りを持っていることを観察しています。

したがって、サプライチェーン最適化戦略の実装を担当するチームから自由を奪うのではなく、サプライチェーンイニシアチブ全体に光を当てるメトリクスのセットを作成することが重要です。管理の役割は、これらのメトリクスを基にしたルールを強制することではなく、メトリクスの基になる戦略的思考に対して挑戦することです。頻繁に、即時の目標はメトリクスの値を改善することではなく、メトリクス自体の定義を改善することであるべきです。

実際には、すべてのメトリクスがビジネスにとって同じくらい価値があるわけではありません。ビジネスに意味のある視点を提供するメトリクスを作成するには、通常、かなりの努力が必要です。この作業には、ビジネス戦略の良い理解だけでなく、多くのアーティファクトや数値の奇妙さを伴う基礎データの深い知識も必要です。したがって、メトリクスはすべて進行中の作業として考えるべきです。

サプライチェーンプロジェクトにおける成功の強力な指標は、イニシアチブ全体で確立されているメトリクスの品質です。しかし、これは少し矛盾しているのですが、それらのメトリクスの妥当性を実際に評価するための合理的なメトリクスは存在しません。以下に、メトリクスの品質を評価するのに役立ついくつかの要素を示します：

• 異なるサプライチェーンチーム内で、メトリクスがビジネスの本質を捉えているとの合意はありますか？または、メトリクスによって暗黙的に推進されるビジネスの視点は、短期的なものでも盲目的なものでもありませんか？
• メトリクスは、数値と経済ドライバーを調和させる際に本当の深さを持っていますか？シンプルさは望ましいですが、全体像を誤解することを優先することはありません。
• データのアーティファクトは適切に処理されていますか？通常、会社のシステムから抽出したデータを処理する際には、数十の微妙な「落とし穴」に注意を払う必要があります。生データが十分に良いように見える場合、問題がすでに識別されていない可能性があるため、疑わしいと考えるべきです。
• 選択したメトリクスから生成される意思決定は意味をなしていますか？メトリクスと一致しているにもかかわらず、意味をなさないと感じる意思決定がある場合、それはおそらくメトリクス自体に問題があることが多いです。

多くの点で、良いメトリクスを作成することは、重力を成功の底に向けることに似ています：何かが介入しない限り、自然な行動の結果は底に向かって転がることです。底がどのくらい深いかを正確に知る必要はありません。旅のすべての段階が会社のために事態を改善している限りです。

理性的な意思決定はパフォーマンスを向上させる

サプライチェーンでは、最良のメトリクスでも大きな欠点があります：数字は通常、パーティーに遅れてやってきます。リードタイムは長く、今日行われた決定が数週間、もしくは数か月後にはっきりとした影響を持たない場合があります。さらに、反復的かつ増分的な改善に重点を置いた量的サプライチェーンは、この問題をさらに複雑にします。ただし、非増分的な方法を使用することは、他の理由でさらに悪い結果をもたらすでしょう。したがって、メトリクスだけを使用してイニシアチブが正しい方向に進んでいるかどうかを評価するためには、他の信号も必要です。

理性的な意思決定を生成することは、単純でありながらも過小評価されている優れたパフォーマンスの信号です。実際には、サプライチェーンチームが手動で修正することで、システムがすでに「非合理な」意思決定を生成し続けている可能性が高いです。すべての「アラート」や同様の反応メカニズムの目的は、継続的な手動の修正作業を通じて問題を軽減することです。

量的サプライチェーンイニシアチブを完全にロボット化された意思決定が「理性的」または「安全」と見なされるようにすることは、ほとんどの実践者が認識している以上に大きな成果です。ここで「ロボット化された」意思決定に重点を置いています：ルールに従ってプレイするためには、人間の介入は必要ありません。そして、「理性的」とは、数時間かけてケースを調査した後でも実践者にとってまだ良いと思える意思決定を指します。これは、毎日行われる同様の意思決定の数のため、定期的に行うことはできません。

私たちの経験から、自動化された意思決定が信頼性があると見なされると、その意思決定が実際に「本番」で使用されるときにパフォーマンスが具現化されます。実際、この「理性」のテストは、意思決定ロジックに対する非常に厳しいテストです。量的サプライチェーンに非常に類似したものを既に活用している場合を除いて、おそらくあなたの会社が持っている既存のシステムは、このテストに合格するには程遠いでしょう。その結果、見落とされたミスが常に発生し、会社はこの継続的な問題のストリームに多額の費用を支払うことになります。

したがって、サプライチェーンの意思決定が自動化されると、サプライチェーンチームは自分たちのシステムに絶え間ない手動のエントリーを供給するという奴隷の立場から解放されます。その生産性の向上は、サプライチェーン戦略の微細な部分を洗練するために、またはサプライヤーをより詳細に監視して彼らの側から発生するサプライチェーンの問題に対処するために、実際に重要な場所に再投資することができます。サプライチェーンの純粋な量的最適化によって達成されるパフォーマンスの向上は、プロセスとワークフローを改善する時間を最終的に見つけることができるサプライチェーンチームによって得られる利益によって強化されます。