Lokadプラットフォーム

数量的なサプライチェーンの取り組みは、プログラミング言語を使用して任意のプラットフォームで実行できますが、Lokadプラットフォームはこれらの取り組みをサポートするために特別に設計されています。 Lokadは、特注の「サプライチェーン予測最適化アプリ」の設計と展開に特化したプラットフォームです。一般的な開発ツールと比較して、Lokadは優れた生産性、信頼性、保守性、セキュリティ、そして何よりもサプライチェーンのパフォーマンスを提供します。

Lokadの中核には、Envisionというドメイン固有のプログラミング言語（DSL）があります。この言語はサプライチェーンの専門家を対象としており、ソフトウェアエンジニアではありません。私たちの主な目標は、サプライチェーンの最適化を、その分野に直接の専門知識を持つ人々の手に置くことです。これにより、LokadはビジネスとITの間に存在する中間層を取り除くことで、サプライチェーンの取り組みをリスクを軽減します。

Envisionを通じて、私たちはAPS（高度な計画システム）、名前だけの「高度な」BI（ビジネスインテリジェンス）、さらには専門の予測ツールキットと比較して、はるかに優れた機能を提供しています。さらに、Pythonなどの一般的なプログラミング言語と比較して、Lokadはより安全で保守性の高いアプリを提供します。

スプレッドシートを超えて

Excelはサプライチェーンで最も広く使用されているツールです。Lokadでは、Excelには多くの素晴らしい特性があることを認識しています。それはシンプルで表現力があり、視覚的であり、何よりも重要なのは、Excelを使用すると常にデータを把握できることです。Excelは当然の成功を収めました。Envisionでは、Excelに見られるこれらの優れた特性をすべて保持するために非常に努力しています。

ただし、サプライチェーンに関しては、Excelは分析の頂点ではありません。Excelの最大の強みは同時に最大の弱点でもあります。計算ロジックとデータが絡み合い、シートが大きくなると問題が絶えず発生します。しかし、サプライチェーンでは、通常、同じ会社内に数百、数千の製品が存在するため、大きなExcelシートは避けられません。

残念ながら、このロジックとデータの絡み合いの問題はExcel内で修正することはできません。なぜなら、修正するとExcelが最初に優れたツールになった理由に反するからです。その結果、Lokadでは、Excelの貴重な特性をサプライチェーンに関して保持しつつ、数億の注文やSKUにスケーリングすることが必要な場合に対応するEnvisionという技術を設計することにしました。

そのため、スプレッドシート、単にExcelだけでなく、サプライチェーンの最適化に必要な特殊で重要な計算クラスには適していません。たとえば、スプレッドシートには確率的な予測を管理するための（ほぼ）機能がありません。そのため、スプレッドシートはサプライチェーンにとって有害な「平均値でのドライブ」の考え方にとらわれています。同様に、スプレッドシートには不確実な条件下での制約最適化を実行するための（ほぼ）機能がありません。その結果、MOQ（最小注文数量）などのありふれた制約も、サプライチェーンの実務者が手動で解決する必要があります。

Envisionは、サプライチェーンの予測最適化に不可欠な、スプレッドシートでは利用できない特殊な構造（例えば、確率変数の代数）を提供します。そのため、Envisionで構築されたアプリは、複雑な問題に対してスケーリングが劣るスプレッドシートよりもはるかに保守性が高くなります。

データを観察するだけでなく、行動する

ビジネスインテリジェンス（BI）ソリューションは、Excelの次の段階として頻繁に販売されています。しかし、Lokadの数年にわたる経験に基づいて、サプライチェーンに関しては、BIはほとんど常に期待される効果を実現できないという結論に至りました。問題は、ビジネスインテリジェンスツールの品質にはありません。BI市場は成熟しており、優れたソリューションが存在します。むしろ、問題は、数千の製品や数千の顧客が関与するビジネスにとって、「洞察を得るためのデータを観察する」ということが非常に高コストになるという事実にあります。

サプライチェーンでは、BIツールはスケーリングに失敗します。それは、利用可能なすべてのデータを処理できないためではありません - Excelとは異なり、優れたBIツールは非常に大量のデータを処理できます - しかし、毎日数百万の数値を生成することは安価ですが、読み取りやすく行動を起こす価値のある10個の関連する数値を毎日生成することは非常に困難です。すべての欠点にもかかわらず、Excelにはこの「物事を成し遂げる」姿勢がありますが、BIにはありません。

Envisionでは、この「物事を成し遂げる」視点を絶対に保ちたかったのです。Envisionはアプリの構築に関するものです。例えば、Envisionは次のような優先順位付けされたアクションリストを生成することができます：

競合他社に圧力をかけるために低い粗利益で維持する必要のあるトップアイテムのリスト
次に注文するコンテナを正確に満たすために必要な数量を生成する
倉庫を整理するために処分する必要のあるトップアイテムのリスト
常に顧客から返品され、削除する必要のあるトップアイテムのリスト

Envisionによって生成された数量的な意思決定は、ERPに自動的に再インポートするか、スプレッドシートとしてダウンロードすることができます。Envisionの具体的な範囲は、あなたがビジネスの最優先事項とするものによって異なります。

ビジネスはプログラム可能性を避けることはできません

Envisionはプログラミング言語です。ソフトウェア開発者ではないほとんどの人々にとって、これは「非常に」技術的に感じるかもしれません。最大の企業でも、ほとんどのビジネスエグゼクティブは、自分のチームがこのような高度なツールを使って生産的になることができるかどうか疑問に思っています。私たちの経験から、サプライチェーンは必ずしも複雑です。私たちは、実際の「9歳の子供」が提供する結果と一致する結果を出すことができるほど簡単なツールを約束するベンダーを目撃しました。

サプライチェーンには数千の製品が関与し、しばしばそれ以上のものもあります。すべての価格、在庫レベル、アソートメントは常に調整する必要があります。これらの日常的なタスクを満足のいく生産性レベルで達成するためには、自動化することが不可欠です。ただし、自動化だけでは十分ではありません。特定のビジネスドライバーと深く連携したスマートな自動化でなければなりません。この「プログラム可能」な部分が、この連携を実現することができる要素です。

あなたの組織のどこかでスプレッドシートで複雑な数式を作成している人がいる場合、その人はスプレッドシートのプログラム的な表現力を活用しています。チームがシステムにドメインの専門知識を注入するためのより良い代替手段を持っていない限り、スプレッドシートの混乱からは逃れられません。Envisionはまさにこの優れた代替手段として意図されています。

Pythonを超えて

データサイエンスの取り組みの人気が高まっているにもかかわらず、その圧倒的な大多数は期待に応えることができません。具体的には、初期のプロトタイプは頻繁に有望ですが、これらの取り組みは通常、本番環境に進むことに失敗します。対照的に、Envisionはサプライチェーンの生産を念頭に置いて設計されており、これらの問題のクラスを最大限に軽減することを特に目指しています。これらの失敗の背後には2つの根本的な原因があります。Envision以外のすべての代替手段の利点と欠点について議論することはやや退屈になるため、明確さのために、PythonとEnvisionの選択についての議論に絞ります。

まず、Pythonにはソフトウェアエンジニアが必要です。実際に、Pythonは、他のどのフルフレッジのプログラミング言語と同様に、Pythonでコードを書く人に多くの技術的な複雑さを公開します。サプライチェーンエンジニアリングの専門家であり、ソフトウェアエンジニアでもあることを期待するのは大きすぎます。プログラムの能力は、プロのソフトウェアエンジニアだけでなく、技術的に熟練した人々の幅広いスペクトルにアクセス可能でなければなりません。

次に、急いで作成されたPythonのプロトタイプの保守コストが高騰します。保守コストは管理する必要があります。Pythonはハードウェア的には軽量ではありません。そして、サプライチェーンの最適化問題を解決することは、混沌としたプロセスです。信頼性の低いシステムからのデータを確実にパイプライン化し、不完全で絶えず変化するプロセスを文書化し、モデル化する必要があります。最適化メトリクスは常に変動するビジネス戦略を反映する必要があります。Pythonは、そのような取り組みをサポートするための設計上の正確さをほとんど提供していません。

これらの課題に対する私たちの回答がEnvisionです。Envisionは、Pythonでは簡単には実現できない方法で輝いています。具体的には、以下のような点です：

深層防御：一般的なプログラミング言語が関与する場合に発生するセキュリティの問題のクラス全体を防ぎます。
透明なパフォーマンス：本番環境で実行するのに非現実的に遅いプログラムを最初に書くことを防ぎます。
透明なアップグレード：常に移動するターゲットと同じくらい最新の状態で、アップグレードは通常、バックグラウンドのコードの書き換えを介して自動的に提供されるべきです。
パッケージ化されたスタック：最も単純なアプリを考慮しても、数十のソフトウェアの組み立ての負担がなくなります。

結論として、Pythonは素晴らしい言語ですが（本当にそうです）、Envisionのようなサプライチェーンの最適化には満足のいく答えではありません。Pythonで本番環境で動作する製品レベルの機械学習アプリを構築し、保守することは可能ですが、コストが高くなります。また、このアプリの保守に専任のソフトウェアエンジニアリングチームを持つ準備ができていない場合、本番環境での動作はうまくいきません。