Lokadの技術は非常に進化しており、2年前にLokadを試したことがある人でも、現在のアプリをほとんど認識できないでしょう。

「古い」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レポートと同様に、_正規化された_データではなく、_ネイティブデータ_に向けた移行は、ビジネスとの整合性を確保するために「少し多く」投資することが結果を「はるかに多く」生み出すという私たちの経験に従っています。