サプライチェーン最適化に関しては、課題に対応すると同時に、プロセスに導入される現実の歪みを最小限に抑えることが重要です。ツールは、課題を歪めてツールに合わせるのではなく、課題そのものを受け入れるべきです。

2年前、私たちはEnvisionを導入しました。これは、サプライチェーンで見つかる非常に多様な状況に対応するために明確に意図されたドメイン固有の言語です。Envisionは、従来のサプライチェーンツールと比較して、プログラムの表現力を提供していました。しかし、この柔軟性は、Envision自体がサプライチェンデータに対して取る実際の視点によって制限されていました。

数ヶ月前、Envisionに汎用のJOINメカニズムを導入しました。Envisionは、最初は「自然な」結合に制限されていましたが、より広範な表データを処理することができるようになりました。サプライチェーンでは、任意のテーブル結合は、マルチソーシング、ワンウェイ互換性、マルチチャネルなどの複雑なシナリオに対応するために特に有用です。

SQLにすでに精通している読者にとっては、テーブルの結合はかなり基本的な操作のように感じるかもしれません。しかし、SQLでは、複雑な数値計算とテーブルの結合を組み合わせると、ソースコードが不明瞭で冗長になることがあります。さらに、大きなテーブルを結合すると、パフォーマンスの問題がいくつか発生し、SQLクエリ自体を調整するか、_テーブルインデックス_を導入することで注意深く対処する必要があります。

Envisionの主な設計目標の1つは、サプライチェーン最適化の課題に直面した際のコーディングのオーバーヘッドを大幅に削減するために、SQLの一部の機能を犠牲にすることでした。その結果、最初のEnvisionは「自然な」結合に基づいており、通常SQLで行われるJOIN操作に関連するほとんどのコーディングオーバーヘッドが削除されました。

ナチュラル結合には制限がありますが、Envision内でleft-by構文を導入することで、これらの制限を解消しました。left-byステートメントを使用することで、Envision内で任意のテーブルを結合することが可能になります。内部では、Envisionが最適化されたインデックスを作成して、巨大なデータファイルを扱う場合でも計算を高速に行います。

純粋な構文の観点から見ると、left-byはEnvision言語における小さな追加ですが、サプライチェンの観点から見ると、この1つの機能により、Lokadは最も複雑な状況に対応する能力が大幅に向上しました。

_もしも、サプライチェンのエキスパートであるデータサイエンティストを社内に持っていない場合、Lokadがいます。Lokadは、サプライチェーンソリューションの実装について世話をするエンドツーエンドのサービスを提供します。