製品指向のサプライチェーン配信 (講義 1.3 要約)

サプライチェーン最適化 supply chain optimization (SCO) の目的は、高価で反復的な一連の 平凡な決定 を自動化するソフトウェアアプリケーションを提供または改善することで、経営陣のバンド幅をより緊急な課題に振り向けることにあります。このアプリケーションは、サプライチェーンそのものと同様に、単なる運用コストではなく、本質的かつ長期的な価値を有する資産と見なされるべきです。しかし、そのような資産のためのソフトウェア要件は、主流のサプライチェーン理論やツールの範囲をはるかに超えており、冒険的なオフィス定番であるExcelも含んでいます。

講義を見る

サプライチェーンは OpExではない

従来のサプライチェーン手法は、ソフトウェアの代わりに人手を活用する傾向があります。これは、Excelスプレッドシートを用い、事務員のチームがほぼ毎日手動で決定を考案・修正していることに現れています。その結果、管理コストの増加や火消し業務の増大、そして例外や緊急事態に対処するための莫大な人的リソースの消耗が招かれています。

サプライチェーンは前述の通り、事業運営における日常的な経費、すなわち運用費用 (OpEx) として扱われていますが、これはサプライチェーンが企業にとって本来持つ関係性を誤解したものであります。しかし、従来のサプライチェーン調整に莫大なリソースが必要とされる現状を考えれば、このOpEx分類も必然的なものと言えます。

従来のサプライチェーンシステムでは、給与、福利厚生、研修、技術的なオーバーヘッドなどが各事務員に対して割り当てられ、サプライチェーンは設計上、常に手動での微調整を必要とするものとなっています。これは、実際には日々繰り返される平凡な作業に対して、過剰な支出を強いる結果となっています¹.

これは、単に平凡な作業を手動で実行することに伴う失われた作業効率や、例外発生時の絶え間ない火消し業務を考慮に入れているだけでなく、その結果として誤って割り当てられた集中力のコストが、事務員だけでなく監督者、管理者、さらには経営幹部にも波及することを意味します.

サプライチェーンは 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のような既製ソフトウェアを無理に企業環境に導入するのではなく、サプライチェーンを念頭に置いて設計されたソフトウェアが求められるのです.

注釈