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

Joannes Vermorel

サプライチェーンには、エンタープライズソフトウェアのパッチワークが含まれています。これらのソフトウェア層は、過去40年間にわたって徐々に、そして時には無秩序に展開されてきました¹。尊敬されるEDI（電子データ交換）は、ブロックチェーンのプロトタイプの隣に座っているかもしれません。このようなシステムは、生産、保管、輸送、請求、コンプライアンスなど、日常的でありながら重要なサプライチェーンの側面を主に操作しています。

これらのシステムは、R＆D目的のクリーンなデータ環境を提供するために設置されたものではありません。この単一の事実が、ほとんどの予測イニシアチブ、そして一般的にはほとんどのデータサイエンスイニシアチブがサプライチェーンで失敗する理由です。逸話的な証拠として、倉庫に保管されているすべての商品を別の場所に物理的に移動する方が、すべてのIT配管を新しい場所に移行するよりも速いことが通常です。

この複雑さの結果として、「現代的な」サプライチェーンのイニシアチブの展開には、あまりにも多くの専門家が関与しています。大規模な企業にとって、典型的なサプライチェーンプロジェクトには次のような要素が含まれます：

• プロジェクトを指導し、トップマネジメントを支援するコンサルタント。
• 追加のIT配管に関連するリスクを評価するITインフラの専門家。
• 関連するシステムの関連するテーブルを特定するデータベース管理者。
• データロジスティクスを確保するパイプラインを設計するETLの専門家。
• 繊細なITパーツに関して追加の手助けを提供するITコンサルタント。
• IT関係者とサプライチェーン関係者をつなぐプロジェクトコーディネーター。
• 経営陣のためにほとんどのレポートを作成するビジネスアナリスト。
• 予測モデリングの部分を担当するデータサイエンティスト。
• 導入される技術のバグを解決するベンダーテクニカルサポート。
• 期待値を管理し、途中で「もの」を追加販売するベンダーの営業担当者。
• 「顧客の声」を代表するサプライチェーンの実践者。
• イニシアチブを推進するサプライチェーンのエグゼクティブ。

しかし、多くの専門家が関与することによって、さまざまな問題が生じます。誰もが、トップマネジメントさえも、何が起こっているのか本当に理解していません。ITの部分は、IT関係者以外の誰にとっても不透明です。逆に、ITはサプライチェーンだけでなく、多くのフロントで苦戦しており、解決しようとしている問題の細部を詳細に解決する余裕がほとんどありません。さらに、データサイエンスは、コンサルタント、IT、およびサプライチェーンの実践者にとってもほとんど不透明な別の学問です。

さらに、第三者、コンサルタント、IT企業、およびテクノロジーベンダーは、会社の目標とは一致しない独自のアジェンダを持っています。プロセスの各段階でいくつかの追加の摩擦²を確保することで、予備的な予算で事業を開始し、徐々にリソースを注ぎ込む必要があることが「驚くべき」こととして成長することができます。

上記にリストされている複雑さの一部は不可避ですが、一部は偶発的です。あるCEOが自分の会社の半分が価値のないことを知っているが、どの半分かはわからないという古いジョークがあります。

この点において、テクノロジーベンダーとしてのLokadの戦略は、この「偶発的な複雑さ」に正面から取り組むことです。その要点はシンプルです: 関与する専門家の数を「劇的に」減らすことです。サプライチェーンサイエンティストという名前の一人の人物が、生の入力データから最終的なサプライチェーンの意思決定までのITパイプライン全体に取り組みます。サプライチェーンサイエンティストは、パイプライン上で起こるすべてのことに対して完全な責任を負います - 機械学習などのスマートな要素も含まれます。

一般的なエンタープライズソフトウェアは、サプライチェーンが直面する多様な問題に対応するために「設定ツール」では表現力が不足しているため、サプライチェーンと互換性がありません。プログラミング言語³が必要です。残念ながら、Pythonなどの一般的なプログラミング言語は、サプライチェーンサイエンティストの役割とは互換性がありません。スキルの要件が高すぎるため、会社内でこれらの役割はソフトウェアエンジニアに委ねられます。ソフトウェアエンジニアを持つことには何も問題はありませんが、サプライチェーンの専門知識はソフトウェアエンジニアではない専門家を通じて再導入される必要があります。やがて、上記にリストされている役割のほとんどがイニシアチブの一部となります。

ただし、サプライチェーンサイエンティストがこれほど多くの役割を果たすためには、専用のプログラミング環境が必要です。それは、サプライチェーンの予測最適化の課題に対処するために、最小限の手間で取り組むことができるものです⁴。Lokadのこの問題への技術的な回答は、Envisionというドメイン固有言語です。

Envisionのコンセプトは、正確に間違っているよりもおおよその正確さの方が良いという考えに基づいています。一人の専門家がサプライチェーン全体の状況を把握できることは、その状況の一面にしか精通していない10人の専門家よりも合理的な解決策を生み出す可能性がはるかに高いです。また、委員会によって生み出される解決策と比較して、一人の専門家によって生み出される解決策はほとんど常によりシンプルでメンテナンスが容易です。

ほとんどのエンジニアリング分野では、委員会が問題に取り組むことの利点が、委員会の存在によって導入される追加の摩擦を軽減します。しかし、サプライチェーンでは、これはほとんど当てはまりません。一人の専門家（または少なくとも数人）によって生み出される戦略の「エンドツーエンド」の一貫性は、委員会が必ず提供する「ローカル」な最適化のほとんどを上回る傾向があります。需要と供給の調整は、根本的にシステムレベルの課題です⁵。

サプライチェーンサイエンティストの主な価値は、会社のトップマネジメントが策定した戦略から、生の電子レコードまでのサプライチェーン全体を包括するシステムレベルでの運用です。ただし、孤独な存在ではなく、サイエンティストは多くの助けを得ます。ITは関連するデータへのアクセスを容易にし（データを事前処理しようとはしません）、オペレーションはプロセス、運用上の制約、およびさまざまなオーバーヘッドを文書化します。マーケティングは会計帳簿から読み取ることができない機会費用、例えば在庫切れのコストを明確にします。トップマネジメントはビジョンを具現化し、最初にサイエンティストが最適化すべきものを明確にしますなど。

サプライチェーンの意思決定⁶は、多くの場合、多くの人々に責任が分散された「システム」の産物ではありません。これらの意思決定は、サプライチェーンサイエンティストが実装した数値レシピの産物であり、企業全体に対するパフォーマンスに対する所有権を持つ単一の思考です。この人は間違いを com することもありますが、必要に応じて引き継ぐ準備ができている同僚など、多くの助けを得ています。私の経験では、これはサプライチェーンを最適化するための唯一の方法であり、どんな規模の委員会でも、KPI、チャート、レポートの下にすべての観察者を埋めることを試みることになるでしょう。