Lokadの技術は非常に進化しており、2年前に試してみた人でさえ、今日のアプリをほとんど識別できないでしょう.

「古い」Lokadは完全に予測エンジンを中心としており、つまり、現在のLokadアカウントで見られる_予測プロジェクト_と同じものです。その結果、予測エンジンは、_統計_とは全く関係のない多数の機能を徐々に獲得しました。約2年前、予測エンジンはほぼすべてを担う万能選手と化していました:

  • データ準備 - 多様なデータ形式に対応する可能性を有します
  • レポーティング分析 - やや複雑で、かつ柔軟なExcel予測レポートを備えています
  • 定期実行 - webcron連携またはAPIを通じて行われます

その後、過去2年間で、当初予測エンジン内に存在した機能のスタンドアロンの代替機能を徐々に導入してきました。しかし、これらの新機能を単なる_代替_と呼ぶのは不当です。なぜなら、これらの代替機能は元の機能よりもはるかに強力だからです.

  • 現在、サイズ、複雑さ、さらにはデータ形式が異なる非常に多様なファイルを処理できるようになりました。さらに、多くのデータコネクタも用意しています.
  • 従来のExcel予測レポートの機能は、Envisionの最新のレポーティング機能に比べて圧倒的に見劣りします.
  • スケジューリングとオーケストレーションは、他のアプリからのデータ取得も含む、一流の機能として扱われています.

これらの新機能が従来のものより明らかに優れているため、我々は予測エンジン内に残っている予測以外のあらゆるもの、すなわち_無駄な部分_を徐々に廃止していく段階に入っています.

プロセスを円滑に進めるために、我々は旧Lokadから新しいLokadへの移行を段階的かつ積極的に進めており、古い機能が使われなくなった際には、それを完全に削除しています.

従来のExcel予測レポートは、我々にとって困難なケースです。課題は単にそのレポートをEnvision内に複製することではなく(それ自体は全く難しくありません)、このレポートに込められた根底の_思考_がすでにかなり時代遅れであるという点にあります。実際、これまでの数年間で、Lokadはより優れた予測技術を導入しており、最新の形態は確率的予測 - これらはこのレポートに組み込むことができません。設計上、この1つのレポートは_レガシー_な予測手法に固執しており、残念ながら在庫最適化には適切ではありません.

対照的に、確率的予測経済的ドライバーを組み合わせるには、Lokad側もクライアント側もより多くの努力が必要ですが、そのビジネス成果は圧倒的です。前者は_誤差のパーセント_の最適化に関するものであるのに対し、後者は_誤差のドル_を最適化します。予想通り、クライアントが後者を採用しないことによる金銭的損失の大きさに気づくと、決して前者に戻ることはありません.

次に、我々のデータ統合も、同様でありながらも決して妥協しない抜本的な変革を遂げています。データコネクタの開発を開始した際、Lokadの予測エンジンが確立したフレームワークに合わせて取得するすべてのデータを収めようと試みました。つまり、Lokad_Items.tsvLokad_Orders.tsvなどのファイルを出力することです。このアプローチは一見魅力的でした。なぜなら、Lokadが取得および処理するデータに対して_正規化_を強制するものであったからです.

しかし残念ながら、この抽象化は―すべての抽象化と同様に―漏れが生じます。すべてのアプリが、何が_製品_であり、何が_注文_であるかについて一致しているわけではなく、考慮すべき微妙な差異が数多く存在し、あらゆるビジネス上の微妙な点を何らかの_正規化_で吸収することは不可能でした.

そのため、データ統合の課題に対して別の角度から取り組み始めました。すなわち、アプリのデータを、できる限り元の構造と概念を_保持_しながら取得するというものです。このアプローチの主な欠点は、Lokadの既定の期待値に適合するようにデータを事前に変換しないため、初期の作業がより多く必要になる点です.

しかし、データが誤った変換を受けないため、ビジネス上の微妙な点を_フレームワーク_に合わないという理由で取り込めなくなることがなくなります。いくらかのプログラム的な接着剤を用いることで、我々はビジネスの要件を細部に至るまで対応しています.

従来のExcelレポートと同様に、_正規化_されたデータではなく_ネイティブデータ_への移行は、数字をビジネスに合わせるために_少しだけ_余分な投資を行うことが、_非常に大きな成果_を生むという我々の経験に基づいています.