Lokad プラットフォーム

定量的サプライチェーンの取り組みは、どのプログラミング言語を備えたプラットフォーム上でも実施可能であるにもかかわらず、Lokad プラットフォームはこれらの取り組みを支援するために緻密に設計されています。Lokad は、カスタムの サプライチェーン予測最適化アプリ の設計と展開に特化したプラットフォームです。一般的な開発ツールと比較して、Lokad は生産性、信頼性、保守性、セキュリティ、そして何よりもサプライチェーンのパフォーマンスにおいて優れた成果を提供します.

Lokad の中核には Envision というドメイン特化型プログラミング言語 (DSL) が存在します。この言語はソフトウェアエンジニアではなく、サプライチェーンの専門家向けに設計されています。我々の最重要目標は、サプライチェーン最適化をその分野に直接精通した人々の手に委ねることです。これにより、ビジネスと IT の間の仲介層を排除し、サプライチェーンの取り組みのリスクを低減します.

Envision を通じて、我々は APS (先進的計画システム) や、名ばかりの「先進的」な BI (ビジネスインテリジェンス)、さらには専門的な予測ツールキットの能力を大きく凌駕します。何よりも、Python のような一般的なプログラミング言語と比較して、Lokad はより安全で保守しやすいアプリケーションを提供します.

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

Excel はサプライチェーンにおいて最も広く使用されているツールです。Lokad では、Excel が持つシンプルさ、表現力、視覚性、そして何よりも常にデータを把握できるという優れた特性を認識しています。Excel はその相応の世界的成功を収めました。Envision では、Excel に備わるこれらすべての優れた特性を維持するために多大な努力を注いできました.

しかしサプライチェーンにおいては、Excel が解析の頂点というわけではありません。Excel の最大の強みでもある特性が、同時に最大の弱点ともなっています。計算ロジックとデータが体系的に絡み合い、シートの規模が拡大し始めると果てしない問題を引き起こすのです。それでも、同一企業内に数百、あるいは数千の商品が存在するサプライチェーンでは、大規模な Excel シートは避けられません.

残念ながら、このロジックとデータの絡み合いの問題は、Excel 内で解決することはできません。というのも、その「解決策」が Excel を偉大なツールたらしめる本質に反してしまうからです。そこで Lokad では、サプライチェーンにおける Excel の貴重な特性を維持しつつ、必要に応じて数億件の注文や SKU のスケールアップにも対応できる技術として Envision の設計を決断しました.

つまり、Excel に限らずスプレッドシートは、サプライチェーン最適化に必要な専門的でありながら不可欠な計算を行うための設計にはなっていません。例えば、スプレッドシートには 確率的予測 を管理する機能が（実質的に）存在しません。そのため、スプレッドシートはサプライチェーンに有害な「平均値による推論」という考えにとらわれます。同様に、スプレッドシートには不確実な条件下での制約付き最適化を行う機能も（実質的に）存在しません。その結果、MOQ（最低発注数量）などの些細な制約でさえ、サプライチェーンの担当者が手動で解決せざるを得なくなります.

Envision は、サプライチェーンの予測最適化に不可欠な、ランダム変数の代数のような専門的な構造を提供します。これらはスプレッドシートでは全く利用できません。また、Envision を用いて構築されたアプリは、複雑な問題に対してスケールが低いスプレッドシートと比べ、はるかに保守性に優れています.

データを単に観察するだけでなく、活用する

ビジネスインテリジェンス（BI）ソリューションは、Excel の次の段階として提供されることが多いです。しかし、Lokad の長年の経験から、サプライチェーンにおいては BI はほとんどの場合、期待される効果を実現できないという結論に至りました。問題は BI ツールの質にあるのではなく、BI 市場は成熟しており、優れたソリューションも存在するにもかかわらず、数千の商品や数千の顧客が関わるビジネスにおいて「洞察を得るためだけの」データ観察が非常に高コストである点にあります.

サプライチェーンにおいて、BI ツールがスケールしないのは、利用可能なすべてのデータを処理できないからではありません（優れた BI ツールは Excel と異なり膨大なデータを処理できます）が、先に述べたように、毎日何百万もの数値を生成するのは容易ですが、読むに値し実際に行動に移すに足る関連性の高い数値をたった 10 個だけ生成するのは極めて困難であるためです。数多くの欠点があるにもかかわらず、Excel は「成果を出す」姿勢を備えていますが、BI にはそれがありません.

Envision では、私たちはこの「成果を出す」という視点を絶対に保持したいと考えました。Envision は アプリ を構築するためのものです。例えば、Envision は以下のような優先順位付きアクションリストを生成できます:

競合他社に圧力をかけるため、低い粗利益率で維持すべき上位の商品をリストアップする
次に注文されるコンテナをちょうど満たすために必要な数量を算出する
倉庫の整理のために一掃する必要がある上位の商品をリストアップする
顧客によって頻繁に返品され、販売停止すべき上位の商品をリストアップする

Envision によって生成された定量的な判断は、その後 ERP に自動的に再取り込みされたり、スプレッドシートとしてダウンロードされたりします。Envision の正確な範囲は、あなたのビジネスの最優先事項として何を決定するかにかかっています.

あなたのビジネスはプログラム可能性を逃れられない

Envision はプログラミング言語です。ソフトウェア開発者でない多くの人にとって、これは非常に技術的に感じられるでしょう。どんな大手企業の経営幹部であっても、自社のチームがこのような高度なツールを使いこなせるかどうか疑問に思うものです。我々の経験は、サプライチェーンが避けがたいほど複雑であることを示しています。実際、「9歳の子供でも使える」ほどシンプルなツールを約束するベンダーを目の当たりにし、最終的には実際の「9歳の子供」が出す結果と同様のものしか得られなかったのです.

サプライチェーンは数千、場合によってはそれ以上の商品が関与します。すべての価格、在庫レベル、品ぞろえは常に調整されなければなりません。これらの日常的な作業を自動化しなければ、満足いく生産性の向上は望めません。しかし自動化だけでは不十分です。特定のビジネスドライバーに深く連動したスマートな自動化が必要であり、この「プログラム可能」という要素こそが、その連動性を実現する鍵となるのです.

組織内のどこかで誰かが複雑な数式をスプレッドシートに作成しているとき、その人はスプレッドシートの持つプログラム的表現力を活用しています。チームが自らの専門知識をシステムに反映するためのより良い代替手段を持たなければ、スプレッドシート依存の状態を打破することはできません。Envision はまさに、この優れた代替手段として設計されています.

Pythonを超えて

データサイエンスの取り組みの人気が高まっているにもかかわらず、現実はその大多数が期待に応えられていないことを示しています。より具体的には、初期のプロトタイプはしばしば有望に見えるものの、実運用へと昇華する段階で失敗するのが常です。それに対し、Envision はサプライチェーンの実運用を念頭に置いて設計され、こうした問題を可能な限り軽減するよう工夫されています。これらの失敗の根本原因は二つあります。Envision の他の代替案の長所と短所をすべて議論するのは冗長になるため、ここでは明確さのために Python と Envision の選択に絞って話します.

第一に、Python はソフトウェアエンジニアを必要とします。実際、Python は本格的なプログラミング言語として、コードを書く人に膨大な技術的複雑さを露呈します。サプライチェーン工学とソフトウェア工学の両方の専門家であることを期待するのは、あまりにも困難です。プログラム的な能力は、プロのソフトウェアエンジニアだけでなく、広範な技術志向の人々にも利用可能でなければなりません.

第二に、急ごしらえの Python プロトタイプの保守コストは天文学的になります。保守コストは抑えられる必要があります。Python はハードウェアリソースの面でも決してスリムではありません。さらに、サプライチェーン最適化の問題を解決するプロセスは煩雑です。多数の（信頼性の低い）システムからのデータを確実にパイプライン処理し、不完全で常に変化するプロセスを文書化・モデル化し、最適化指標が絶えず変動するビジネス戦略を反映する必要があるなど、課題は山積みです。Python はそのような取り組みを支えるための「設計による正しさ」をほとんど提供しません.

Envision は、これらの課題に対する我々の解答です。Envision は、Python では到底実現できない方法で輝きを放ちます。具体的には:

ディフェンス・イン・デプス：汎用プログラミング言語が関与する際に生じる、一連のセキュリティ問題を未然に防ぎます.
透明なパフォーマンス：そもそも運用で実用に耐えないほど遅いプログラムが書かれるのを防ぎます.
透明なアップグレード：最新技術が常に変化する中で、アップグレードは通常、バックグラウンドでのコード書き換えを通じて自動的に提供されるべきです.
パッケージ化されたスタック：最もシンプルなアプリであっても、数十のソフトウェア部品を組み合わせる負担が排除されます.

結論として、Python は素晴らしい言語ではあるものの、Envision のようにサプライチェーン最適化に対する十分な解答とはなりません。Python で運用レベルの機械学習アプリを構築・保守することは可能ですが、そのコストは高く、もし貴社がそのアプリの保守に専任のソフトウェアエンジニアリングチームを配置する覚悟がなければ、運用ではうまく機能しないでしょう.