解決策ではなく問題に恋をする
各々のSKUは、在庫を増やすか、基になる価格を変更するなど、日常的な決定を必要とします。当然、これらの決定に完全に手動プロセスを採用することは労働集約的であり、企業はさまざまなソフトウェアベースの自動化ソリューションを採用してきました。これらのソリューションに対する最も一般的な設計戦略は、既存の「人間」の実践に本質的に類似したものをソフトウェアで再現しようとすることです。
このアプローチは新しいものではありません。おそらく、専門家システムが強調した視点は、1980年代後半から1990年代初頭の第2次AI冬においてほとんどが不名誉に終わったものです。しかし、バズワードである「専門家システム」はもはや存在せず、現在でも「専門家システム」のベンダーとして自社をブランド化している（重要な）ソフトウェアベンダーはいないと思いますが、基本的な視点がほとんどの垂直市場で依然として広まっていることに気付かずにはいられません。
実際、ほとんどのソフトウェアベンダー、およびほとんどの社内イニシアチブも、既存の実践を再現する視点に固執しています。この実践自体は、元々完全に手動のプロセスを模倣することから生まれました。古い専門家システムは、より現代的なディープラーニングアルゴリズムの対応品に置き換えられたかもしれませんが、全体像のパラダイムは（ほぼ）変わっていません。
サプライチェーンでは、このパターンは顕著です。ほとんどの実践は、コンピュータが存在しなかった時代に生まれたアプローチに固執しています。たとえば、多くの企業はまだ「計画チーム」と「需要予測を立てる人々」と「供給チーム」と「需要予測に基づいて発注を行う人々」とを区別しています。このアプローチは、従業員が仕事で最大限のパフォーマンスを発揮するためにできるだけ専門化する必要があるというテイラー主義の視点から生まれました。
しかし、サプライチェーンの最適化に関しては、テイラー主義はサプライチェーンの現実とは相容れません。現実は、将来の需要は現在の決定とは独立していないことを示しています。もしもはるかに大きな発注が行われ、単位購入価格が大幅に低下する場合、販売価格も低下し、市場と競争する可能性があり、その結果需要が大幅に増加するかもしれません。コンピュータのない世界では、テイラー主義は非常に効率的ではありませんが、非常にスケーラブルです。しかし、コンピュータのある世界では、そのようなフィードバックをある程度でも考慮した統合的なアプローチが求められます。言い換えれば、「正確に間違っているよりもおおよそ正しい方が良い」ということです。
この問題についてクライアントや見込み客に問いただすと、状況はしばしば明確ではありません。純粋に手動のプロセスを再現するために設計されたソリューションは長い間存在しており、人々は解決しようとしている問題のより基本的な側面を見失ってしまいました。頻繁に、人々は現在のソリューションの欠点として認識されているものに「固執」してしまい、解決策の専門家になることよりも、会社が直面している問題の専門家になることを忘れてしまいます。したがって、状況を改善しようとする際には、すべての考えが現在のソリューションの欠点に「固定されて」いるというバイアスがあります。このバイアスのため、アプローチは問題を徹底的に再評価し、そのためには経営陣とチームの両方から「リスキー」と見なされます。逆に、既存のソリューションを段階的に改善するオプションは「安全」と見なされます。少なくとも、はるかに「安全」です。
L3 企業ソフトウェアの歴史を振り返ると、ベンダーが「新しい方法」を強制するという話がたくさんありますが、それは古いプロセスよりもはるかに手間がかかり、柔軟性に欠けるものでした。その結果、生産性の向上はゼロまたはマイナスになりました。私の経験から、大規模なサプライチェーンを運営する多くの企業は、過去20年間にわたってホワイトカラーの労働力をほとんど削減していませんが、ブルーカラーの労働力はより効率的な工場や倉庫によって積極的に自動化されています。これらの不幸な出来事は、新しいソフトウェアソリューションに準拠するための疲れ果てた「再編成」に対するエコシステムに健全な懐疑心を注入しました。
ただし、サプライチェーンのエグゼクティブは、どんな「スマート」なソフトウェアにも関連するリスクを大幅に過小評価しているとも指摘しています。つまり、正確に簡潔に指定できないソフトウェアです。実際、ほとんどの企業ソフトウェアは、請求書、サプライヤー、製品、支払いなどの日常的なリストの忠実な簿記係に過ぎません。
「愚かな」ソフトウェアでビジネスの成功を達成すること自体が非常に困難です - 多くの電子商取引企業は既にウェブフロントエンドの正常な稼働時間を維持するのに苦労しています - しかし、機械学習のような神経質なソフトウェアが関与する場合、成功を達成することははるかに困難になります。多くの企業がこの問題について公にコミュニケーションを取っていませんが、機械学習が関与すると、失敗が支配的になります。ただし、状況は思われるほど暗いわけではありません。デメリットは限られており、メリットは限りなくあります。
したがって、長期的には、最も多くの試行と失敗をする企業が最も成功する企業であることがわかります。
それにもかかわらず、ソフトウェアのリスクは非常に現実的なものであり、それ以上のリスクを増やす意味は全くありません。ただし、廃れた手動のプラクティスを再現するというパラダイムに固執することは、偶発的な複雑さの連鎖を引き起こします。たとえば、計画チームと供給チームが異なる場合、これらのチームを同期させるために問題のクラス全体が発生します。ソフトウェア開発の経験則として、要件を25%増やすとコストが200%増加します。これらの複雑さの解決はコストを大幅に増加させ、実際にはリスクを増加させます。なぜなら、企業は予算や納期を超えるイニシアチブを終了する傾向があるからです。
したがって、ソフトウェアを組織に合わせるか、組織をソフトウェアに合わせるかという50年前の問題に直面した場合、知的にはまっさらな状態から始めて、まず解決すべき高レベルの問題が何であるかを把握することが賢明です。パフォーマンスはパーセンテージで測定されますか？それともドルで測定されますか？長期的な影響を正しく計算していますか？たとえば、顧客にセール時のみの購入を訓練していますか？アプローチは人間の入力を活用していますか、それともそれらの入力を単に消費していますか？実践は習慣によって駆動していますか、それとも命令的な必要性によって駆動していますか？たとえば、1年に2つのファッションコレクション対、1年に2つの収穫対。
問題自体とその現在の解決策を明確に区別する、問題を解決するための深い理解は、既存の解決策を維持する価値があるかどうか、それとも問題のより単純で直接的な解決策を求める新しいソフトウェアの機能に簡略化すべきかを見極めるための鍵です。
