最適化のメンテナンス

Joannes Vermorel

Lokadが企業のクライアントに請求する料金はシンプルです¹：ソフトウェアと専門家の組み合わせに対する一律の月額料金²。驚いたことに、当社の月額料金はオンボーディングフェーズの終わりに急激に減少するのではなく、時間の経過とともに一定です。しかし、多くの人々は驚くことはありません。なぜなら、ベンダーからの欲望に満ちたばかげたデモンストレーションに直面することは、エンタープライズソフトウェアの世界ではただの月曜日だからです[/ja/ベンダー/]。しかし、これは無駄な貪欲さの教科書的なディスプレイではありません。むしろ、この料金は持続的なサプライチェーンのパフォーマンスを実現するために必要なものです。

エンタープライズソフトウェアベンダーにとって最も利益の上がる道は、常に「お金をもらって逃げる」ことです。ライセンス料はまるでお金を印刷するようなものです。ライセンスに比べて統合はより困難です。リスクは高く、利益率は薄いです。そのため、大手ベンダーは通常、ヒートを受けることができる統合業者のネットワークを育成することで、この部分を完全に委託しています。しかし、ベンダーの観点から見ると、最も利益の上がらない部分は、間違いなくメンテナンスです。逸話的に言えば、ベンダーはかなりのメンテナンス料を請求しているにもかかわらず、クライアントにアップグレードを義務付けています。メンテナンス料はかなりのものですが、ベンダーが自社のレガシーをサポートするために必要なものには程遠いです。

サプライチェーンの最適化は、ベンダー（Lokadではない）がメンテナンスを「排除」した特殊なケースです。ただし、この「成功」は、クライアントが想定していたものではないことは確かです。

1980年代以来、ベンダー（Lokadのようなベンダーですが、数十年前から）はサプライチェーンの意思決定を自動化するためのソフトウェアを提供してきました³。それ以来、ほとんどの大企業は1つではなく、しばしば複数のこのようなソリューションを取得しています。1990年代には、エンタープライズリソースプランニング（Enterprise Resource Planning）という言葉がこの「計画」の自動化を目指す野望から生まれました。さもなければ、ERPはERMSと呼ばれ、企業リソース管理を意味することになるでしょう。

しかし、サプライチェーンの意思決定の自動化は実現しませんでした。システムは導入されましたが、それらはほとんど使用されず、または元のミッションを回避しています⁴。その結果、ほとんどのサプライチェーンはスプレッドシートを介して管理されており、最適化ソリューションが最初は成功と見なされていたとしても、メンテナンスに何か問題があったことを証明しています。

これらの失敗はソフトウェアベンダーにとって利益があります。ベンダーはライセンス料を手に入れ、場合によってはマルチイヤーコミットメントの形で受け取ります（SaaSの場合）。ソリューションが機能していないため、メンテナンスはほとんど必要ありません。クライアントは使用していないソフトウェアの機能について心配する必要はなく、その結果、ベンダーにはあまりプレッシャーをかけません。元のソリューションのうち、基本的な自動化ルールを管理するための薄いデータ入力ゲートウェイの断片のみが使用され続けています（たとえば、SKUのmin/max設定）。

一方、Lokadは本格的な自動化されたサプライチェーンの意思決定を提供することに成功しています。ただし、それを実現するためには、クライアントに専任のタスクフォースである「サプライチェーンサイエンティスト」（Lokadの用語で）による継続的な取り組みが必要です。サイエンティストは、関心のあるサプライチェーンの意思決定を生成する数値レシピを作成し、後で維持する責任があります。

生成された数値レシピは放置しておくことができます。これがサプライチェーン最適化の文脈での「本格的な」自動化の意味です。したがって、サプライチェーンサイエンティストはいつでも会社にとって害を及ぼすことなく、取り除くことができます。

とはいえ、サプライチェーンは常に変化するものであり、それには自然に連鎖効果があります。私たちのアルゴリズムは流量の変化に対応できますが、本格的な数値レシピを維持するために必要な他の微妙な変化に対応できるアルゴリズムはまだありません。

その結果、サプライチェーンサイエンティストは、Lokadが本番環境にある場合に対処する必要がある一連のタスクを抱えています：

• 新しいデータが利用可能になり、数値レシピを更新してこの新しいデータを活用する必要があります。逆に、一部のデータソースが廃止され、数値の依存関係を適切に切断する必要があります。大規模な企業では、アプリケーションのランドスケープは、ERPのアップグレード中だけでなく、常に進化しています。

• 会社の戦略が変わります。数値レシピはクライアントの戦略的意図の反映であり、この反映は数値のパラメータの値を選ぶ以上のものです。サプライチェーンサイエンティストが戦略の変化に対応するためにレシピの一部を完全に書き直すことは一般的ではありませんが、時折それが起こります。

• 信頼性を維持する必要があります。サプライチェーンのリーダーシップは、数値レシピが適切に機能していることを示す継続的な証拠をサプライチェーンサイエンティストに求めています。サイエンティストは、新しいパフォーマンス指標を反映するための新しい計測機器を提供するだけでなく、リーダーシップが出す質問に対応することも期待されています。

• 透明性を維持する必要があります。サイエンティストは数値レシピの「ホワイトボックス化」に責任を持っています。これには、チームに適切な理解レベルを持たせるためのトレーニングが含まれます。チームが入れ替わると、新しいメンバーにトレーニングを行う必要があります。

これらのタスクのいずれかに失敗すると、サプライチェーンの実践者はスプレッドシートに戻るしかありません。

したがって、数値レシピは数週間放置しておくことができますが、時間の経過とともにその関連性は必ず低下します。そのため、数値レシピを関連性のある状態に保つためには、継続的なエンジニアリングリソースが必要です。人工知能の最近の進歩にもかかわらず、自己メンテナンスが可能なソフトウェアをエンジニアリングすることは、現在の技術水準を超えています。書くのは議論の余地があるかもしれませんが、このタスクは人工汎用知能の達成の難しさと同じくらい難しいと思われます。

サプライチェーンサイエンティストからの継続的な貢献が必要であるという点は理解できますが、数値レシピが本番環境にあると、これらの取り組みが減少すると思うことも許されます。しかし、私たちの経験からは、数値レシピの複雑さは、利用可能なエンジニアリングリソースのレベルに合わせて必ず拡大します。

過去10年間、リソース投資に関して転換点を何度も観察してきました。数値レシピの設定に最初に投資されるリソースが、会社が年間に投資する予定のリソースを上回る場合、数値レシピはその製品レベルの状態を維持するために必要な適切なケアを受けることができません。この見落としの最も頻繁な症状は、重要ではあるが即座には重要ではないすべての要素に対する長期のバックログです：ドキュメンテーション、コードレビュー、コードのクリーンアップ、計測など。

ビジネスの成功を保証するテクノロジーやプロセスはありませんが、適切なメンテナンスは会社をゼロに戻し、スプレッドシートの海に溺れさせるための確かなレシピです。お避けいただけるサプライチェーンの失敗の増加台帳に、貴社が別のデータポイントにならないようにしてください。