供給チェーン向けの製品指向配信（講義1.3の要約）

供給チェーンの最適化（SCO）の目的は、繰り返し行われる高額な決定を自動化し、管理の帯域幅を解放することです。このアプリケーションは、供給チェーン自体と同様に、組織にとって固有の長期的な価値を持つ資産として考慮されるべきです。ただし、このような資産に対するソフトウェアの要件は、Excelなどの主流の供給チェーン理論やツールの範囲をはるかに超えています。

講義を視聴する

供給チェーンはOpExではありません

伝統的な供給チェーンの手法では、ソフトウェアの代わりに人力を活用する傾向があります。これは、Excelのスプレッドシートを使用してほぼ毎日のように決定を考案し、修正する職員チームに反映されています。これにより、オーバーヘッドが増加し、消防活動が増加するだけでなく、供給チェーンにおいて一般的な数多くの例外や緊急事態を手動で処理し対応するために膨大な帯域幅が割り当てられます。

上記のように表現される供給チェーンは、事業の日常的な経費（OpEx）として扱われます。これは、供給チェーンが事業に対する真の関係を誤解していることを反映しています。ただし、伝統的な供給チェーンの維持には膨大なリソースが必要であるため、OpExの分類は驚くべきことではありません。

伝統的な供給チェーンシステムでは、給与、福利厚生、研修、技術的なオーバーヘッドなどが職員ごとに割り当てられ、設計上、常に手動で調整が必要なものとなります。これは、実質的には繰り返し行われる単調なタスクのシリーズであり、通常は毎日行われます¹。

これには、単調なタスクの手動実行に関連する帯域幅の損失だけでなく、例外が発生した場合の常時の消防活動も含まれません。そのような誤った集中のドルコストを計算することは困難ですが、その浪費の要因には、職員だけでなく、その上司、マネージャー、さらにはCスイートの役員も含まれます。

供給チェーンはCapExです

Lokadの立場は、供給チェーンを*資本支出（CapEx）*として再構築すべきであるというものです。それは、建物や機械、車両などと同様に、会社にとって戦略的な資産であり、ソフトウェア会社が基盤となる製品を中心にビジネスを構築するのと同様に、スケーラブルで利益を上げることができます。この場合、製品は高価な人的投入を必要とする単調な日々の決定を自動生成するための数値レシピです。

このような人的投入は、おそらくある程度の精度の決定をもたらすでしょうが、ソフトウェアベースの相手と比べて、財務的にも帯域幅的にもはるかに高いコストがかかります。日々の業務では、このような数値レシピである供給チェーン最適化（SCO）は、組織内の他の高価値な機械と同様に静かに独立して実行されます。

SCOが考慮する必要があること

ある会社のSCOには、さまざまな考慮事項があり、ビジネスの種類によって異なります。これにより、標準の棚卸しSCOを購入するという考え自体が無効になります。

B2B企業とB2C企業の文脈でSCOを考えてみましょう。後者は前者よりもはるかに多くの顧客を持つ場合があり、平均的な顧客を失っても気づかれないかもしれません - 例えば、何千人もの定期的な顧客を持つスーパーマーケットの場合です。B2B企業は通常、B2C企業よりもはるかに少ない顧客を持つため、一つの顧客を失うことは壊滅的な結果になる可能性があります - 例えば、顧客がスーパーマーケットであるサプライヤーの場合です。

したがって、一つの顧客の固有の価値は、自分の視点によって変わり、この視点が会社が設定すべきサービスレベルや安全在庫の目標を決定します。この確固たる第一原則を超えて、B2B企業とB2C企業は、在庫SCOを活用するという考え自体が非常に困難になるユニークな制約を持っています。これには以下のような要素が含まれます：

在庫： SKUは速い動きですか、遅い動きですか？腐敗しやすいですか？ 注文： 顧客はスポット注文ですか、計画された注文ですか？注文は設定可能ですか？ 価格： いくら請求しますか？価格は一定ですか？忠誠度カードやボーナスはありますか？

これらの要素だけでも導入される変動は数え切れないほどありますので、標準のSCO製品を展開しようとすることは、無駄な高価な試みになります。

SCOが行う必要があること

SCOは典型的なソフトウェアではありません。他の資産とは異なり、供給チェーンは、アクター、材料、そして自然と市場の力という散在した配列です。そのため、SCOに対する要求は、背後で動作するERPなどの見かけ上の類似ソフトウェアに期待されるものをはるかに超えます。このようなソフトウェアにはアジリティの期待はありませんが、SCOはアジリティだけでなく、決定力も持たなければなりません。

このアジリティの重要な要素は、SCOが敵対的な脅威に対してどれだけ迅速かつ明確に対応できるかです。これらは、ビジネスに対して非常に高い財務リスクをもたらす脅威のクラスであり、迅速かつ明確な介入を要求します。Excelはその強みにもかかわらず、この種の脅威に対応するために設計されておらず、それが発生した場合に意思決定の推奨を提供することもありません。

たとえば、航空会社の全機が急なリコールにより運航停止となった場合や戦争や津波が発生した場合、Excelは完全に無力です。これらのイベントのいずれかがサプライチェーンにとって壊滅的な影響を与える可能性があります。したがって、緊急事態にインテリジェントな推奨を行うことができるSCOが必要です。さらに、これらの脅威は迅速に計算され、対応する必要があります。これらの脅威に対処するための時間枠は、時間単位で測定されます。日単位ではなく（もちろん、月単位でもありません）。

このようなレスポンスのレベルは、従来のサプライチェーン管理のプラクティスでは実現不可能です。その多くは、官僚的な基準ですら膨張しています。SCOは、サプライチェーンのような物理的かつ地理的に分散したネットワークが遭遇する脅威に対してレスポンスをプログラムする最良の方法です。

SCOの秘密の要素

SCOの成功には、個々のソフトウェア機能や要素の多くが必要ですが、大まかなカテゴリは次のように要約できます：

• 多目的データストレージ： SCOは膨大な量のデータを保存し、アクセスできます。
• プログラム可能なロジック： SCOは異なる問題に対応するために適応できます。
• 多目的なユーザーインターフェース： SCOは関連するデータを表示します。
• 協力能力： SCOには多くの人々が相互作用できます。
• 専門家でなくても利用可能： SCOは誰にでも操作可能です。

Excelなどのアプリケーションは、上記の要件のほとんどを満たしていると言えますが、これはサプライチェーンの万能薬ではなく、このドキュメントで説明されているSCOの要求を満たしているわけではありません。言い換えれば、ExcelがSCOの目的に一部成功して利用されることは、それが最良の選択肢であることを意味するわけではありません²。

たとえば、Excelは大量のデータを保存および処理できるとはいえ、数十万行、もしくは数百万行のデータを安定して処理するためには適していません。Excelは非SCO関数の文脈ではプログラミングロジックの表現力が非常に高いですが、ランダム変数を用いた計算などは適していません。

一見すると、これは些細な制約のように思えるかもしれませんが、このプログラミングの欠陥は、Excelでの確率的予測が非常に困難であることを意味します。確率的予測は、優先的な在庫補充などの意思決定ポリシーの基盤です。SCOにとって、これらの機能がなければ意味がありません³。

要するに、成功するSCOには、企業のミックスにExcelのような既製のソフトウェアを押し付けるのではなく、サプライチェーンを考慮したソフトウェアが必要です。

ノート