サプライチェーンの電球を交換するのに、何人必要ですか？

Joannes Vermorel

サプライチェーンはエンタープライズソフトウェアの寄せ集めを含みます。これらのソフトウェアレイヤーは、過去40年にわたり徐々に、時にはでたらめに展開されてきました¹。伝統的なEDI（電子データ交換）が、ブロックチェーンのプロトタイプの隣に位置しているかもしれません。このようなシステムは、生産、保管、輸送、請求、コンプライアンスなど、平凡だが不可欠なサプライチェーンの側面を主に運用しています。

これらのシステムは、研究開発目的のためにクリーンなデータ環境を提供する意図で設置されたものではありません。この一事実だけで、ほとんどの予測プロジェクト、そしてより一般的に多くのデータサイエンスプロジェクトがサプライチェーンにおいて失敗する理由が説明されます。逸話的な例として、倉庫に保管されている全商品の物理的な移動は、すべてのIT配管を新しいサイトに移行するよりも通常速いのです。

この複雑さの結果、「現代的な」サプライチェーンの取り組みの展開には、例外なく_過剰な_専門家が含まれます。大企業の場合、典型的なサプライチェーンプロジェクトは以下のようなメンバーで構成されます:

• プロジェクトを指揮し、経営陣を支援するコンサルタント。
• 追加のIT配管に伴うリスクを評価するITインフラの専門家。
• 関連するシステムの関連テーブルを特定するデータベース管理者。
• データロジスティクスを確実にするパイプラインを設計するETLの専門家。
• 繊細なIT部分を補助するITコンサルタント。
• IT担当者とサプライチェーン担当者を調整するプロジェクトコーディネーター。
• 経営陣向けのレポートの大部分を作成するビジネスアナリスト。
• 予測モデリングを担当するデータサイエンティスト。
• 導入される技術のバグを解決するベンダーの技術サポート。
• 期待値を管理し、途中で「追加のもの」をアップセルするベンダーの営業担当者。
• 「顧客の声」を代表するサプライチェーンの実務者。
• この取り組みを推進するサプライチェーンのエグゼクティブ。

しかし、専門家が多数関与することは、それ自体でさまざまな問題を引き起こします。経営陣でさえ何が起きているのかを十分に理解できないことが多いです。ITに関する部分は、IT担当者以外には常に不透明です。逆に、ITはサプライチェーンに限らず多方面で多忙を極めており、解決すべき問題の細部を検証する余裕がほとんどありません。さらに、データサイエンスは、コンサルタント、IT、そしてサプライチェーン実務者にとってほとんど不透明な別の分野を加えることで、問題をさらに悪化させます。

さらに、第三者、コンサルタント、IT企業、およびテックベンダーは、それぞれ独自のアジェンダを持っており、これは会社のものとは一致しません。プロセスのあらゆる段階で余分な摩擦²を生み出すことで利益を得るチャンスがあります。これにより、初めはごく僅かな暫定予算でスタートし、時間の経過とともに投入すべきリソースが増えるにつれて、予算が「驚くべきほど」着実に増加することになります。

上記の複雑さの一部は解消不可能ですが、もう一部はかなり偶然の産物です。すべてのCEOが知っている古典的なジョークに、「会社の半分は何の価値も生み出していないが、どちらの半分かは分からない」というものがあります。

この点において、テックベンダーとしてのLokadの戦略は、この_偶然の複雑性_に正面から取り組むことでした。その要点はシンプルです：関与する専門家の数を_劇的に_削減することです。たった一人、つまりサプライチェーン・サイエンティストが、生データの入力から最終化されたサプライチェーンの意思決定に至るまでの全ITパイプラインを担当します。サプライチェーン・サイエンティストは、パイプラインで起こるすべてのこと、機械学習を含むスマートな部分まで、その成果に対して全責任を担います。

従来のエンタープライズソフトウェアは、サプライチェーンが直面する問題の多様性に対処するには『コンフィギュレータ』が表現力不足であるため、サプライチェーンと互換性がないのです。³プログラミング言語が必要です。残念ながら、Pythonのような一般的なプログラミング言語は、サプライチェーン・サイエンティストの役割と互換性がないのです。求められるスキルレベルが非常に高く、社内ではその役割がソフトウェアエンジニアに分散してしまいます。ソフトウェアエンジニアを起用すること自体は問題ではありませんが、サプライチェーンの専門知識は、ソフトウェアエンジニアでない専門家を通じて再導入されなければなりません。やがて、上記の大部分の役割がこの取り組みの一部となるのです。

しかし、サプライチェーン・サイエンティストがこれほど多くの役割を兼任するためには、専用のプログラミング環境が必要です。つまり、余計な煩雑さ⁴を極力排除しながらサプライチェーンの予測最適化の課題に取り組むことが可能な環境です。Lokadのこの問題に対する技術的解決策は、Envision, a domain-specific languageでした。

Envisionの概念は、「大雑把に正しい方が、正確に間違っているよりも良い」という考えに根ざしています。サプライチェーン全体の状況を把握できる一人の専門家は、状況の一部分しか把握していない10人の専門家よりもはるかに合理的な解決策を生み出す可能性が高いです。さらに、委員会が生み出す解決策と比較して、一人の頭脳が生み出す解決策はほとんどの場合、シンプルで保守が容易です。

ほとんどの工学分野では、委員会が問題に取り組むことで得られる利点が、委員会の存在自体がもたらす余分な摩擦を相殺します。しかし、サプライチェーンにおいては、これはめったに当てはまりません。単一の頭脳、あるいは少数の専門家によって生み出される戦略のエンドツーエンドの一貫性は、委員会が必然的に提供する多くの『局所的』最適化を凌駕する傾向にあります。需給の調整は本質的にシステムレベルの課題です⁵.

サプライチェーン・サイエンティストの最大の価値は、原始的な電子記録から経営陣が策定する戦略に至るまで、サプライチェーン全体を包括するシステムレベルで活動できる点にあります。しかし、孤独な存在であるどころか、科学者は多くのサポートを得ています。ITは、（データを_preprocess_しようとせずに）関連データへのアクセスを容易にし、オペレーションは現行のプロセス、運用上の制約、および各種の間接費を文書化します。マーケティングは、財務諸表からは読み取れない機会費用、例えばストックアウトコストを明確にします。トップマネジメントはビジョンを明確化し、そもそも科学者が何を最適化すべきかを定義します。

結局のところ、サプライチェーンの意思決定⁶は、責任が多数の、しばしば数十人に分散される「システム」の産物ではありません。これらの意思決定はすべて、サプライチェーン・サイエンティストという一人の頭脳によって実装された数値的レシピの産物であり、会社全体に対するパフォーマンスの責任を引き受けています。この人物は誤りを犯すこともありますが、必要に応じて引き継ぐ同僚を含む多くの助けを得ています。私の経験では、たとえ大規模な委員会が反対を証明しようとするために、すべての観察者をKPI、チャート、レポートで埋め尽くすにしても、サプライチェーンの_最適化_を開始する唯一の方法です。