Lokad プラットフォーム

このロジックとデータの混在は、Excel の強みを壊さずに解消することができません。そこで Lokad は、表計算の価値ある性質を保ちながら、数億件の注文や SKU まで拡張できる技術として Envision を設計しました。

さらに、表計算はサプライチェーン最適化に不可欠な一部の専門的計算に向いていません。たとえば 確率的予測 を扱う機能はほとんどありません。そのため、意思決定は「平均値で運転する」発想に閉じ込められます。同様に、不確実性の下で制約付き最適化を行う手段もほぼありません。結果として MOQ のような基本的な制約でさえ手作業に頼ることになります。

Envision は、ランダム変数の代数のような専用構成要素を提供します。これはサプライチェーンの予測最適化に不可欠であり、表計算には存在しません。また Envision で構築されたアプリケーションは、複雑化した表計算モデルよりもはるかに保守しやすくなります。

Envision ではこの行動志向を必ず残したいと考えました。Envision は アプリケーション を構築するためのものです。たとえば次のような優先アクション一覧を生成できます。

• 競合に圧力をかけるため、粗利益を低く維持すべき商品
• 次のコンテナを正確に満たすために必要な発注数量
• 倉庫を整理するため優先的に処分すべき商品
• 顧客から繰り返し返品され、品揃えから外すべき商品

Envision が生み出す定量的意思決定は、そのまま ERP に自動再投入することも、表計算として出力することもできます。Envision の適用範囲は、貴社が何を最優先事項とみなすかによって決まります。

サプライチェーンは数千の商品を含み、しばしばそれ以上です。価格、在庫水準、品揃えは常に調整されなければなりません。こうした反復作業を自動化しなければ、十分な生産性は望めません。しかし自動化だけでは不十分です。必要なのは 賢い自動化 であり、ビジネス上の論理に深く整合していなければなりません。その整合を実現するのがプログラマビリティです。

組織のどこかで誰かが表計算に複雑な式を書いているとき、その人はすでに表計算のプログラム的表現力を使っています。業務知識をシステムへ注入するより良い選択肢がない限り、この表計算依存から抜け出すことはできません。Envision はそのためのより優れた代替手段として設計されました。

第一に、Python にはソフトウェアエンジニアが必要です。Python は汎用言語であるため、多数の技術的詳細をコード作者に露出させます。一人の人間にサプライチェーン工学とソフトウェア工学の両方を求めるのは無理があります。プログラム能力は、専門のソフトウェアエンジニアだけでなく、幅広い技術志向の人々が使えるべきです。

第二に、急ごしらえの Python プロトタイプは保守コストが急騰します。保守コストは制御されなければなりません。Python は軽量ではなく、サプライチェーン最適化は混沌とした作業です。信頼性の低い多数のシステムからデータを確実に統合し、不完全で変化し続ける業務をモデル化し、最適化指標を変化する経営戦略に合わせ続ける必要があります。Python には、そのような努力を支える設計上の正しさがほとんどありません。

Envision はこの課題への私たちの答えです。Python では到達しにくい点で強みを発揮します。

• 多層防御により、広い範囲のセキュリティ問題を未然に防ぐ
• 透明な性能により、本番で遅すぎるプログラムを書かせない
• 透明なアップグレードにより、バックグラウンドでのコード書き換えを含め進化を自動で届ける
• パッケージ化されたスタックにより、単純なアプリでも大量のソフトウェア部品を組み合わせる負担をなくす

Python は優れた言語ですが、Envision のようにサプライチェーン最適化へ十分な回答を与えるものではありません。Python で本番向けの機械学習アプリを構築し維持することは可能ですが、コストが高く、専任のソフトウェアチームなしでは長続きしません。