最適化のメンテナンス

Joannes Vermorel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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