サプライチェーンの強靭性には帯域幅が必要です

Joannes Vermorel

過去数年間、サプライチェーンにとっては厳しい時期でした。実際、不足していなかった唯一のものは、ロックダウン、戦争、インフレなどの混乱の要因です。その結果、「強靭な」サプライチェーンへの関心が新たに生まれました。 当然のことながら、通常の容疑者であるコンサルタント、教授、およびソフトウェアベンダー（私も含めて）は、「解決策」を見つけるために忙しく働いています。少なくとも、これらの混乱の影響を軽減することができ、最善の場合は、混乱のクラスを完全に排除することができる「解決策」を見つけるために。しかし、私の簡単な観察では、これらの「解決策」は、その認識された価値に関係なく、通常は単なる甘い夢に過ぎません。

実際、過去数十年間、私はほとんどのサプライチェーンディレクターとそのチームが、大規模な混乱のない期間でもマイクロクライシスに埋もれていることを観察してきました。したがって、ほとんどのサプライチェーン部門は、危機管理（または任意の大規模な戦略計画）について考える余裕がありません。彼らは絶え間ない火の手を消し続けることに全力を注いでいます。

数十年前、ソフトウェア業界はこの問題を指すために「帯域幅不足」という用語を作り出しました。つまり、管理者が既に多くの問題に注意を払っているため、別の問題についてさえ「考える」余裕がない状態です。ソフトウェアとサプライチェーンの両方にとって、帯域幅の概念が非常に関連しているのは、通常の企業の対応策が適用されないことです。つまり、スケジュール遅延しているソフトウェアプロジェクトに追加の人員を投入することは、単にさらなる遅延を引き起こすだけです。ソフトウェア業界では、自由市場で運営されてきた最も利益の上がる企業の一部であるにもかかわらず、この帯域幅の問題は非常に厄介です。企業が労働力とその管理を倍増させても、問題には何の影響も与えません¹。

おそらく驚くべきことに（またはそうでもないかもしれませんが）、この絶え間ないサプライチェーンのマイクロクライシスの根本原因は、ほとんどがソフトウェアです。直感に反して、ウクライナでの戦争やアジアでの戦争の可能性がサプライチェーン部門の「帯域幅」を奪うのではなく、通常は「完全に逸話的」と最も適切に評価される問題がそれです。たとえば、WMSがERPと同期していない（…または再び）などの問題、または「予約済み」在庫のための追加のデータベースカスタムフィールドを取得するためのITとの政治活動²、またはS&OPプロセスによって提供される完全に非現実的な予測を追いかけることなどです。

帯域幅を奪うソフトウェアの中でも、分析製品が最も問題です。特に計画ツールは、操作するために多くの人員だけでなく、独自の小さな官僚機構を必要とします。その結果、サプライチェーンの管理部門は、官僚自体が生成するプロセス関連の問題に加えて、ソフトウェア関連の問題を解決する必要があります。このプロセスは非常に反射的であり、ますます帯域幅を浪費します。

title: “分析ソフトウェアの問題”

L7 Lokadは、この分析ソフトウェアエコシステムの一部であるため、この問題に免疫を持っていません。数年前、私たちはマニフェストの第4項目³を通じてこの解決策を開発しました:「制御するためには、毎日の瑣末なタスクを自動化する必要がある」。私たちは、管理と最適化の間で慎重なバランスを取る必要があることに気付きました。たとえば、サプライチェーン部門の帯域幅予算を消費するために、毎日の購買/生産オーダーを生成する場合、改善（弾力性など）のための資金が残りません。

自動化によって、瑣末な決定を自動化することで、サプライチェーンチームは通常、組織がデジタル化された数十年前に失ったものを取り戻すことができます: 戦いを選ぶ能力です。これは、生産性の節約をはるかに上回る、おそらく最も重要な利点です。私は、1980年代と1990年代にデジタルサプライチェーンに移行することが正しい選択でなかったと言っているわけではありません。単純に言えば、このデジタル化の道は_必要_であったとしても、深刻な欠点も伴っていました:（自由市場の）企業は、通常は数年単位で測定される移行とアップグレードが必要な自社のアプリケーションランドスケープに固執していることはなかったのです。多くのサプライチェーンは、アラート、例外、問題の絶え間ないストリームなしで業務を開始することを覚えている従業員はほとんどいません。これには、アラート、例外、問題に対処するための絶え間ないストリームのミーティングも含まれます。これらのプロセスは、帯域幅においてもコストを発生させ、精神的な負担は常に存在します。

実証的な証拠として、1903年から1908年のわずか5年間で、ヘンリー・フォードは何もない状態からモデルTを生み出しました。フォードは産業生産を革新し、その過程でダース以上のモデル（モデルA、モデルB、モデルCなど）を導入しましたが、常に変動する供給と需要を抱えていました。フォードも簡単ではありませんでした: 1907年のパニックは、史上最大かつ最も深刻な金融危機の1つでした。現在では、「いつものようなビジネス」の5年間で、多くの（ほとんどの？）企業はさえないままにERPのアップグレードを完了することができません。

よって、弾力性を持つためには、サプライチェーンは帯域幅を確保する必要があります。弾力性は難しい、捉えどころのないテーマであり、そのためには多くの帯域幅が必要です。さらに悪いことに、ソフトウェア業界が数十年前に発見したように、サプライチェーンには使い捨ての帯域幅が不足しているため、単に莫大な金額を投入することで修正できるわけではありません⁴。むしろ、弾力性への最善の道は間接的なものです: 瑣末な決定を徹底的に自動化し、戦略的な決定（弾力性を含む）を考え、実行する自由を得ることです。