お問い合わせ

Lokad プラットフォーム

定量的サプライチェーンの取り組みは、プログラミング言語を備えた任意のプラットフォーム上で実施できますが、Lokad プラットフォームは、まさにそのために設計されています。Lokad は、サプライチェーンの予測最適化を行う個別仕様のアプリケーションを設計し、導入するための専用プラットフォームです。汎用的な開発ツールに比べ、生産性、信頼性、保守性、セキュリティ、そして何よりサプライチェーンの業績に優れています。
Lokad の予測および最適化技術

Lokad の中核をなす Envision は、ドメイン特化型のプログラミング言語です。ソフトウェアエンジニアではなく、サプライチェーンの専門家のために設計されています。私たちの主な目的は、その業務を直接理解している人々自身がサプライチェーンを最適化できるようにすることです。業務部門と IT の間の仲介層をなくすことで、Lokad は取り組み全体のリスクを下げます。

Envision は、名ばかりの「高度な」計画システム(APS)、ビジネスインテリジェンス(BI)ツール、さらには予測専用のツールキットの能力を大きく上回ります。さらに Python のような汎用言語と比べても、Lokad はより安全で保守しやすいアプリケーションを実現します。

表計算の先へ

表計算の先へ

Excel は依然としてサプライチェーンで最も広く使われているツールです。Lokad もその長所を高く評価しています。Excel はシンプルで表現力があり、視覚的で、何より常にデータを直接確認できます。世界的な成功に値するツールであり、Envision では、こうした長所を維持するために多くの労力を注いできました。

しかしサプライチェーンにおいて、Excel は分析の到達点ではありません。最大の強みは同時に最大の弱みでもあります。計算ロジックとデータが常に絡み合い、シートが大きくなるほど問題が増えていきます。しかも、数百から数千の商品を扱う企業では、大規模なシートはほぼ避けられません。

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

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

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

データを見るだけでなく行動する

ビジネスインテリジェンスのソリューションは、しばしば Excel の次の段階として売り込まれます。しかし Lokad の経験では、サプライチェーンに関して BI が期待された効果を実現することはほとんどありません。問題はツールの質ではありません。BI 市場は成熟しており、優れた製品も存在します。本当の難しさは、何千もの商品と何千もの顧客を抱える環境で、データを眺めて知見を得ること自体に莫大な費用がかかる点にあります。
データに基づいて行動する

サプライチェーンで BI が規模の拡大に対応できない理由は、Excel とは異なり、データ処理能力にあるのではありません。優れた BI ツールは大量のデータを処理できます。毎日何百万もの数値を出す費用はわずかですが、読んで行動に移す価値のある十個の数値を毎日出すことは極めて困難です。欠点は多いものの、Excel では具体的な仕事を進められます。BI にはそれができません。

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

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

Envision が算出する数量などの意思決定は、そのまま ERP に自動で取り込むことも、スプレッドシートとしてダウンロードすることもできます。Envision の適用範囲は、貴社が事業上何を優先するかによって決まります。

企業はプログラマビリティを避けられない

プログラマビリティ
Envision はプログラミング言語です。ソフトウェア開発者でない多くの人には、非常に専門的に聞こえるでしょう。最大規模の企業の経営者でさえ、自社チームがそのような高度なツールで本当に生産性を上げられるのかと懸念します。しかし私たちの経験では、サプライチェーンはどうしても複雑なものです。「9 歳の子供でも使える」と約束するベンダーを見てきましたが、その成果も、9 歳の子供が出す成果と同程度でした。

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

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

Python の先へ

Python の先へ
データサイエンスへの取り組みはますます注目を集めていますが、現実にはその大多数が期待を満たしません。初期の試作品は有望に見えても、本番運用への移行で失敗することが多いのです。Envision はサプライチェーンの本番運用を念頭に設計され、こうした問題を最大限抑えるよう作られています。この失敗パターンには二つの根本原因があります。すべての選択肢との比較は煩雑になるため、ここでは Python と Envision に絞ります。

第一に、Python にはソフトウェアエンジニアが必要です。汎用言語である Python でコードを書くには、多くの複雑な技術事項を扱う必要があります。一人の人間にサプライチェーンとソフトウェア工学の両方の専門性を求めるのは無理があります。プログラミングの力は、専門のソフトウェアエンジニアだけでなく、技術的な素養を持つ幅広い人々が利用できるべきです。

第二に、急ごしらえの Python の試作品は保守コストが急騰します。このコストを抑える必要があります。Python はハードウェア資源を節約する言語ではなく、サプライチェーン最適化も整然とした作業ではありません。信頼性の低い多数のシステムから信頼できるデータパイプラインを構築し、不完全で変化し続ける業務を文書化してモデル化し、最適化指標を変化する経営戦略に合わせ続ける必要があります。Python には、その作業の正しさを設計によって保証する仕組みがほとんどありません。

Envision はこの課題への私たちの答えです。Python では実現できない強みを備えています。

  • 多層防御により、汎用言語で生じる特定の種類のセキュリティ問題を丸ごと防ぐ
  • 性能を透過的に管理し、本番では遅すぎて使い物にならないプログラムの作成を防ぐ
  • 進歩し続ける最新技術を利用者が意識せず取り入れられるよう、通常はバックグラウンドでコードを自動的に書き換えて更新する
  • ソフトウェア構成を一式にまとめ、単純なアプリケーションでさえ数十もの部品を組み合わせなければならない負担をなくす

Python は優れた言語ですが、Envision のようにサプライチェーン最適化の課題に十分に応えるものではありません。Python で本番向けの機械学習アプリケーションを構築し、維持することは可能ですが、コストが高くつきます。専任のソフトウェアエンジニアリングチームを丸ごと用意しない限り、本番では機能しません。