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

Joannes Vermorel

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

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

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

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

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

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

それに対して、すべての瑣末なタスクを完全に自動化すると、サプライチェーン組織から大量の帯域幅が解放されます。ただし、このプロセスには時間がかかります。Lokadがクライアントのために作業を開始してから、戦略的と見なされるような任意の主題に直接焦点を当てることができるまでに、通常約1年かかります（弾力性など）。Lokadは本番環境に移行するだけでなく（約6ヶ月かかります）、組織は自動化されたすべてのプロセスの制御を手放すことも学ばなければなりません（大規模な組織ではさらに6ヶ月以上かかる場合もあります）。

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

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

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