ソリューションではなく、問題に恋せよ
すべてのSKUは、在庫を追加することや基本的な価格表示を変更することなど、日々の些細な意思決定を要求します。当然、これらの意思決定を完全に手動プロセスに依存するのは労働集約的であるため、企業は様々なソフトウェアベースの自動化ソリューションを採用してきました。これらのソリューションにおける最も一般的な設計戦略は、既存の「人間的」な実践と本質的に類似したものをソフトウェアを通して再現しようとする試みです.
このアプローチは新しいものではありません。おそらく、1980年代後半から1990年代初頭の第2次AI冬の間にその評判を失ったエキスパートシステムによって強調された視点だったのでしょう。しかし、流行語となった エキスパートシステム はもはや使われず（現在、「エキスパートシステム」ベンダーと自称する有力なソフトウェアベンダーは存在しないと思います）、根底にある視点が多くの分野で依然として広まっていることに気付かざるを得ません.
実際、多くのソフトウェアベンダーや多くの社内プロジェクトは、完全に手動で行われていた従来のプロセスを模倣することで生み出された現行の実践を再現するという視点に固執し続けています。昔のエキスパートシステムは、より近代的なディープラーニングアルゴリズムに置き換えられたかもしれませんが、全体像としてのパラダイムは（ほぼ）手付かずのままです.
サプライチェーンにおいて、このパターンは特に顕著です。なぜなら、ほぼ全ての実践が、コンピューターが存在しなかった時代に生まれた手法に固執しているからです。例えば、多く―大半の―企業では、各製品の需要予測を立てる_プランニングチーム_と、その需要予測に基づいて発注を行う_サプライチーム_を今なお区別しています。この手法は、従業員が業務において最大限のパフォーマンスを発揮するために、可能な限り専門化されるべきであるというテイラー主義的な視点から生じました.
しかし、サプライチェーン最適化に関して言えば、テイラー主義はサプライチェーンの現実と相反します。現実は、将来の需要が現在の意思決定と切り離せないことを示しています。もしもはるかに大きな発注が行われれば―その結果、単位あたりの購入価格が大幅に下がり―販売価格も引き下げることができ、市場での競争に勝ち、結果的に需要が飛躍的に増加する可能性があります。コンピューターがなかった時代、テイラー主義は非常に効率的ではなかったものの、そのスケーラビリティの高さから最悪ではない選択肢でした。しかし、コンピューターが存在する現代においては、たとえ粗雑であってもそのような逆作用を考慮に入れた、より統合されたアプローチが求められます。俗に言うように、_「大雑把に正しい方が、正確に間違っているよりもまし」_ということです.
この問題についてクライアントや見込み客に問いかけると、状況はしばしば不明瞭となります。元々は純粋な手動プロセスを再現するために設計されたソリューションが長期間使用されてきた結果、人々は解決すべき問題の根本的な側面を見失ってしまっています。あまりにも頻繁に、人々は企業が直面する問題の専門家になるのではなく、現在使われているソリューションの専門家になってしまいます。したがって、状況を改善しようとする際、その考察は文字通り現在のソリューションの欠陥に_固執_してしまいます。この偏りのため、問題を深く再検討するアプローチは、経営陣やそのチームから_リスクが高い_と認識されがちです。対照的に、既存のソリューションを段階的に改善する選択肢は_安全_、あるいは少なくともずっと_安全_であると考えられます.
振り返ってみると、エンタープライズソフトウェアの歴史は、ベンダーが自らの「新しい方法」を無理に押し付けた結果、従来のプロセスよりもはるかに手間がかかり硬直的となり、生産性がゼロ、あるいはマイナスになったという話で溢れています。逸話的には、大規模なサプライチェーンを運営する多くの企業は、過去20年間でサプライチェーンを支えるホワイトカラーの人員を大幅に削減しておらず、その一方でブルーカラーは、より良い工場やより良い倉庫によって積極的に自動化されてきたことが見受けられます。これらの不運な出来事は、新しいソフトウェアソリューションに適合させるための疲弊する「再編」に対し、エコシステム内に健全な懐疑心を植え付けました.
しかし、サプライチェーン-サイエンティストと呼ばれるサプライチェーン幹部は、一般的に「スマート」なソフトウェア、つまりその正しさを完全かつ簡潔に定義できないソフトウェアに伴うリスクを大いに過小評価しているように見受けられます。実際、ほとんどのエンタープライズソフトウェアはCRUDアプリに過ぎず、請求書、サプライヤー、製品、支払いなどの些細な一覧の几帳面な記録係にすぎません.
「愚か」なソフトウェアでビジネス成功を収めることは、既に非常に困難です―多くのeコマース企業がウェブフロントエンドの高稼働率の維持に苦労している中で―しかし、機械学習コンポーネントのような気難しいソフトウェア部品が関与すると、成功を収めるのは_はるかに_困難になります。この件について公然と語る企業はごくわずかですが、機械学習が絡む場合、失敗が全体を支配するのが現実です。しかしながら、状況は見たほど暗くはなく、欠点は限定的である一方で、利点はそうではありません.
したがって、長い目で見れば、最も多く試みて失敗する企業こそが、結果的に最も成功を収める企業でもあるのです.
とはいえ、ソフトウェアに伴うリスクは非常に現実的であり、それらのリスクをさらに高める意味は全くありません。しかし、既に時代遅れとなった手動実践を再現するというパラダイムに固執すると、一連の偶発的な複雑な問題を必然的に引き起こします。例えば、プランニングチームとサプライチームが分割されているため、両者を同期させることだけを目的とした一群の問題が発生します。ソフトウェア開発における経験則として、要件を25%拡大するとコストは200%増加します。これらの問題の解決はコストを劇的に押し上げ、実際には企業が予算や締め切りを炸裂させる取り組みを終結させる（賢明な反応として）結果となるのです.
したがって、ソフトウェアを組織に合わせるか、組織をソフトウェアに合わせるかという半世紀前からの問いに直面した際には、頭を一度白紙に戻し、まず解決すべき高次の問題が一体何であるのかを明確にすることが賢明です。パフォーマンスはパーセンテージで測るのか、それともドルで測るのか？長期的な影響を正しく織り込めているのか？例えば、顧客にセール時のみ購入させるよう訓練する、といった点です。アプローチは人間の入力を活用しているのか、それとも単にその入力を消費しているだけなのか？その実践は習慣によるものなのか、切迫した必要性によるものなのか？たとえば、年2回のファッションコレクションと年2回の収穫のように。
解決すべき問題を深く理解すること―それ自体が現在のソリューションとの明確な違いを示す―こそが、現行のソリューションを維持すべきか、あるいはより新しいソフトウェア機能によってよりシンプルで直接的な解決策へと簡略化すべきかを見極める鍵となるのです.
