サプライチェーンの回復力には帯域幅が必要

Joannes Vermorel

ここ数年、サプライチェーンは決して恵まれた環境にあるとは言えませんでした。実際、欠乏していなかったのは混乱の要因、すなわちロックダウン、戦争、インフレーションなどでした。その結果、『レジリエントな』サプライチェーンへの新たな関心が生まれました。 当然ながら、顧問や教授、そして software vendors（私自身も含めて）といったおなじみの存在たちは、少なくともこれらの 混乱 がもたらす影響を軽減し、最善の場合は混乱の種類を完全に排除する『解決策』の策定に忙殺されてきました。しかし、私の漠然とした観察によれば、これらの『解決策』は、その評価にかかわらず、通常、ただの望み的観測に過ぎないのです.

実際、過去10年間で、ほとんどのサプライチェーンディレクターやそのチームは、たとえ大規模な混乱が少ない期間であっても、すでに多数の小さな危機に埋もれているのを目の当たりにしてきました。そのため、多くのサプライチェーン部門は、危機管理（または大局的な戦略計画）について考える余裕すら持たず、絶え間なく続く火消し作業に全力を注いでいるのです.

数十年前、ソフトウェア業界はこの問題を表現するためにある用語を作り出しました。それが lacking bandwidth であり、経営陣がすでにあまりにも多くの問題に気を取られていて、新たな問題についてさえ 考える余裕 を持てない状態を意味します。帯域幅 という概念がソフトウェアとサプライチェーンの双方において極めて重要である理由は、いずれの場合も、通常の企業の対処法、すなわち「より多くの人員を投入する」という方法が効果を発揮しないからです。これがブルックスの法則の本質、すなわち 既に遅れているソフトウェアプロジェクトに追加の人員を投入しても、単にさらに遅延を招くにすぎない というものです。ソフトウェア業界――自由市場で史上最も収益性の高い企業のいくつかを抱える業界――において、この帯域幅の問題は特に厄介です。たとえ企業が労働力や管理体制を倍増させるほどの利益を上げていたとしても、この問題に対しては何の効果ももたらさないのです ¹.

おそらく意外かもしれませんが（いや、そうでないかもしれませんが）、この終わりなきサプライチェーンの小さな危機の根本原因は、ほぼ専らソフトウェアによるものです。逆説的なことに、ウクライナでの戦争やアジアでの新たな戦争の可能性がサプライチェーン部門の 帯域幅 を圧迫しているのではなく、通常は「全くもって逸話的」と言える事象、たとえば WMS と ERP の同期不良（…再び）や、IT部門との駆け引きによって「予約済み」在庫用の追加データベースカスタムフィールドを確保する事案 ²、または S&OP プロセスによって提供される全くもって不合理な予測に追われるといった問題が挙げられます.

帯域幅を奪うソフトウェアの不名誉な顔ぶれの中でも、解析系製品は圧倒的に最悪の犯人です。これらのツール――特にプランニング系のツール――は、操作するのに膨大な人手を必要とするだけでなく、自ら小規模な官僚組織を生み出します。その結果、サプライチェーンの管理者は、官僚組織自体が生み出すプロセス関連の問題に加えて、ソフトウェアに起因する問題のトラブルシュートを行わなければならなくなるのです。このプロセスは苛立たしいほど反射的となり、さらなる帯域幅を浪費してしまいます.

解析系ソフトウェアのエコシステムの一部であるLokadも、この問題からは免れません。しかしながら、我々は何年も前にマニフェストの第四原則 ³ を通じて、この問題に対する解決策を開発しました。それは、管理を掌握するためにはあらゆる単調な作業の自動化が必要である というものです。我々は、管理と最適化の間に微妙なバランスがあることに気づきました。例えば、日々の購買・生産注文の作成がサプライチェーン部門の帯域幅を全て消費してしまうなら、改善（回復力向上など）に充てる余力は一切残らなくなってしまいます.

逆に、あらゆる単調な作業が完全に自動化されると、サプライチェーン組織から膨大な帯域幅が解放されます。しかし、このプロセスには時間がかかります。Lokadがクライアントのもとで業務を開始すると、戦略的と見なされるテーマ（回復力を含む）に直接取り組むまでに通常約1年を要するのは、決して偶然ではありません。Lokadはまず生産稼働に移行しなければならず（約6ヶ月かかります）、さらに組織は自動化された全てのプロセスのコントロールを放棄する方法を学ばなければならず（大規模な組織ではさらに6ヶ月以上かかります）。

しかしながら、単調な意思決定を自動化することで、サプライチェーンチームは、かつて組織がデジタル化された数十年前に失ってしまったもの、すなわち自ら戦うべき対象を選ぶ能力を取り戻すのです。これは、自動化による生産性向上の節約をはるかに上回る、最も重要な利点と言えるでしょう。1980年代や1990年代に、ERP、MRP、APSといったシステム群を用いて運営されたデジタルサプライチェーンへの移行が誤りであったとは言っていません。簡単に言えば、そのデジタル化の道は 必要不可欠だった ものの、重大な副作用を伴ったのです。（自由市場の）企業は、自らのアプリケーション環境にこれまで以上に埋没し、移行やアップグレードが通常、数年単位で計られる状況に陥っています。多くのサプライチェーンは「デジタル火消し」に長期間巻き込まれ、無限のアラート、例外、問題とともに業務を開始していた記憶のある従業員はほとんどいません。これに加えて、これらのアラート、例外、問題に対処するための終わりなき会議もまた、帯域幅に関わるコストを生み、常に精神的な負担が積み重なっているのです.

逸話的な証拠として、1903年から1908年のわずか5年足らずで、ヘンリー・フォードがゼロからモデルTを生み出した事実を考えてみましょう。フォードは工業生産に革命をもたらし、その過程でモデルA、モデルB、モデルCなど10種類以上のモデルを次々と発表しながら、常に変動する需要と供給のバランスを巧みに操りました。フォードにとっても容易な道ではありませんでした。1907年のパニックは、史上最も偉大かつ深刻な金融危機の一つでした。今日では、通常業務を5年間続けただけで、多く（おそらくほとんどの？）の企業がERPのアップグレードを完了させることすらできないのです.

このように、回復力を高めるためには、サプライチェーンは帯域幅を確保しなければなりません。回復力は捉えどころのない難解なテーマであり、多大な帯域幅を必要とするため、一層の挑戦を強いられるのです。さらに悪いことに、ソフトウェア業界が数十年前に発見したように、サプライチェーンにおける利用可能な帯域幅の不足は、ただ莫大な資金を投入するだけでは解決しません ⁴。むしろ、回復力を実現する最善の道は、単調な意思決定を容赦なく自動化し、その結果、戦略的な判断（回復力を含む）を実行する自由を獲得することにあるのです.