サービスとしてのサプライチェーン

Joannes Vermorel

予測最適化の観点では、ほとんどのサプライチェーンは1990年代初頭に固着しています¹。大企業は過去20年間で一連の『予測』イニシアチブを実施してきました。しかしながら、これらのアップグレードのうちごく一部のみがサプライチェーンに大きな影響を与えました。

10年前、Lokadでは、これらの失敗の根本原因に対処し始めたとき、サービスとしてのサプライチェーン (SCaaS) が Software as a Service (SaaS) モデルに取って代わるビジネスモデルとして登場しました。我々は「ソフトウェア＋エキスパート」サブスクリプションの販売を開始しました。エキスパート、つまりsupply chain scientistは、意思決定を生み出すnumerical recipesを実装し、一方、ソフトウェア、つまりLokad platformが、迅速かつ確実に運用するためのインフラをエキスパートに提供します。

この10年間、我々のSCaaSの実践はサプライチェーンのイニシアチブの成功率を向上させる上で最大の要因、あるいはそれに匹敵する要因となってきました。しかしながら、SCaaSという概念自体に対しては反対意見が頻繁に提起されています。

我々は自社のサプライチェーン能力を外部化しない。 この異議は、戦略的な自社内サプライチェーン能力を維持すべきだという示唆を含んでいます。確かにその場合もありますが、ほとんどの場合、その能力は「戦略的」とは見なされません。大企業を含む多くの会社で、我々の5min supply chain performance testでさえ10点のスコアを達成できていません。さらに悪いことに、S&OPのような大規模なイニシアチブは、意思決定プロセスをさらに細分化することで実際のサプライチェーン能力を着実に_低下_させる傾向があります。

逆に、SCaaSは企業における真の戦略的サプライチェーン能力の出現への道を切り開きます。これは意思決定プロセスの自動化、つまりロボット化から始まります。実際、オートメーションがなければ、サプライチェーンチームは戦略的に考える余裕がほとんどありません。チームのすべてのエネルギーがサプライチェーンの例外的な問題への対応に注がれてしまいます。逆に、SCaaSが導入されると、複数のクライアントが、自社の歴史の中で初めて、カニバリゼーションやMOQの最適化といった困難な問題に取り組む時間を持てたと語っています。

我々はそれを使いやすいツールで実現する。 この異議は、サプライチェーンチームにプログラミングスキルが欠如しているという前提にもとづいており、その結果、特定のツール群を排除してしまいます。サプライチェーンの観点では、主要な「使いやすい」ツールは3種類あります：バニラアプリ、ローコードアプリ、およびスプレッドシートです.

バニラアプリは、サプライチェーンに見られるあらゆる変動に対応するための多数のオプションと機能を備えています。初めはアプリの操作が簡単に感じられます：単なる設定の問題で、その後はworkflowが運用を引き継ぎ、プログラミングは一切不要です。しかし、実際にはサプライチェーンの状況が常にアプリの能力を上回るため、実務者は仕事をこなすためにスプレッドシートに頼らざるを得ません.

ローコードアプリはプログラミング言語を直接扱うことなく、プログラミングの力を提供すると謳っています。通常、何らかのビジュアルエディターを備えています。しかし残念ながら、ローコードアプローチは、日常的なサプライチェーンでさえ直面する複雑さにうまく対処できません。2つのテーブルと10のフィールドを持つ単純な例ではローコードは優秀に見えますが、20のテーブルと500のフィールドを持つ実例では、ローコードは不十分です。ローコードアプリにアクセスが与えられても、実務者は最終的に仕事をやり遂げるためにスプレッドシートに頼ります.

スプレッドシートは、間違いなくサプライチェーン実務者が使用する_決定的な_ツールです。確かに業務はこなしますが、Microsoft Excelであろうとウェブベースの代替品であろうと、スプレッドシートの枠組みに収まらない微妙なニュアンスが存在します。Probabilistic forecastingや確率論的最適化は、そもそもスプレッドシートの領域には属しません。スプレッドシートが関与している限り、SCMの実践は1990年代に固着したままです.

SCaaSは、サプライチェーンのアップグレードを実現するための火花となります。ここ20〜30年にわたって確立された慣行に挑戦することは、すでに困難な戦いです。SCaaSは、他社で既にその経験を持つベテランと共にこの戦いに挑む機会となります.

我々は自社のデータサイエンスチームで実現する。 2000年代初頭、異議は「自社のデータマイニングチームで実現する」と表現されていました。データマイニングは終わり、データサイエンスの時代が幕を開けました。しかし、ほとんどの企業は20年前の失敗したデータマイニングイニシアチブからの教訓を忘れており、技術が失敗の根本原因であることはほとんどなく、実際の問題は象牙の塔にありました.

サプライチェーンに関しては、データサイエンティストの採用はほぼ必ず、遅くて高コストな失敗への道を歩むことになります。データサイエンティストは通常、open sourceのフレームワークや言語のトレーニングを受けた若いエンジニアです。その結果、典型的なデータサイエンティストは前任のデータマイナーと同様に、技術的な視点で世界を見ています。データサイエンスチームは「問題を探す解決策」の継続的な流れを生み出し、講演やデモを行います。サプライチェーン実務者は、データサイエンスチームを丁重に称賛し、その「解決策」が実際の生産に近づかないように配慮するのです。この点において、実務者は正しい判断を下しています.

SCaaSプロバイダーは、装飾的でいる余裕がありません。ほとんどの企業は、会社に貢献していないとしてもデータサイエンティストのような人材の解雇に苦労しています。しかし、十分な成果を上げない第三者のサービスプロバイダーを解雇することには、ほとんど躊躇がありません。SCaaSプロバイダーは、何度もその_継続的な_価値を証明し続ける生存者なのです.

SCaaSプロバイダーとして、Lokadは「サプライチェーンサイエンティスト」役職に純粋なデータサイエンティストを採用することはめったにありません。代わりに、何よりもまずサプライチェーンの専門家になろうとするエンジニアを評価します。統計モデルは手段であって目的ではありません。データサイエンティストは、数値モデルの限界を追求しすぎる傾向があります。サプライチェーンサイエンティストは論文発表を目指しているのではなく、最小限の手間で仕事を完遂したいのです。実際、これが本番環境で稼働するソリューションと、決して本番に至らない派手なプロトタイプとの違いを生み出します.