サプライチェーンのアンチパターン

サプライチェーンの取り組みはしばしば失敗します。量的サプライチェーンは、失敗率を劇的に低下させるための私たちの解決策です。しかし、量的サプライチェーンはうまくいっているとわかっている実践方法に焦点を当てているため、うまくいっていない実践方法にはあまり重点を置いていません。さらに悪いことに、伝統的なサプライチェーンの手法に関連する高い失敗率の正確な根本原因であることが、これらの望ましくない実践方法のほとんどであることがわかりました。

以下では、ほとんどのサプライチェーンの取り組みが失敗する原因となる実践方法、またはパターンについて説明します。これらの洞察は困難な経験から得られました。各洞察については、問題の根本原因を理解するために1回ではなく複数回の失敗が通常必要でした。私たちはこれらの有害な実践方法を「サプライチェーンのアンチパターン」と呼んでいます。アンチパターンとは、裏目に出る「解決策」のことです。一般的なアプローチであり、良いアイデアのように感じられますが、本来求められていた改善を必ずしも提供することができません。

悪いリーダーシップ

Lokadでは、サプライチェーンの意思決定者である重要な人々を敵対視するつもりはありません。彼らは私たちの見込み客であり、クライアントです。しかし、同時に、解決策が設計上失敗することが保証されている場合には、取引を終了する義務があると考えています。頻繁に問題は、イニシアチブ自体の管理方法に帰結します。とはいえ、サプライチェーンの管理は決して唯一の原因ではありません。特定のベンダーは、時にはクライアントに対して全く間違ったメッセージを宣伝し、それを平然と行っています。レガシーな実践方法や内部政治も、サプライチェーンの日常業務を毒してしまうことがあります。また、意図した通りにうまくいかない場合には、サプライチェーンの管理者自体がスケープゴートにされることもあります。このセクションでは、見直されたサプライチェーンのリーダーシップを通じて解決できる一般的な落とし穴をリストアップしています。

地獄のRFQ

RFQ（見積もり依頼）が有効な場面は多くあるかもしれません。ただし、ソフトウェアに関してはその1つではありません。ソフトウェアの仕様を書くことは、ソフトウェア自体を書くよりもはるかに困難です。この作業は困難です。RFQプロセスが開始されると、企業はコンサルタントを導入して状況をさらに複雑にし、既に複雑な仕様をさらに複雑にします。RFQは問題解決の思考を阻害します。なぜなら、RFQプロセスでは、クライアントが望む解決策の詳細をすでに知っていると仮定しているためですが、「問題」は定義上、RFQが書かれた時点ではほとんど解決されていないからです。さらに、実際には、RFQは敵対的なベンダー選択プロセスを促進します。良いベンダーは去り、悪いベンダーが残ります。最後に、ソフトウェアは速い業界です。会社がRFQプロセスを終える頃には、競合他社はすでに自社のソリューションを展開しているでしょう。

脆弱なPOC

POC（概念実証）を行うのは、購入するものが単純な近似商品サービス（例：名刺の印刷サービス）である場合には良いことです。サプライチェーンの取り組みは、設計上複雑です。サプライチェーンには複数のエンティティの調整が必要です。利用すべきデータのレイヤーが複数あります。考慮すべきワークフローは数十あります。POCや小規模なパイロットは、その設計上の性質から、成功したサプライチェーンの取り組みの基本的な利点であるスケールでの運用能力を無視しています。ほとんどの人々は規模の経済の原則に慣れていますが、サプライチェーンの最適化に関しては、主に規模の非経済性に対処する必要があります。つまり、問題の複雑さが増すにつれて、良い意思決定がますます困難になるということです。小規模な配送センターで成功を収めたからといって、数十の異なる配送センターを扱う際にも同じようにうまくいくとは限りません。

不確実性の排除

未来は不確実であり、不確実性を願い事で排除することはできません。同様に、サプライチェーンの数値最適化もまた、願い事で排除することのできない難しい問題です。サプライチェーンの最適化には確率的予測が必要であり、これは不確実な未来と向き合う直接的な結果です。サプライチェーンの最適化は、数値最適化によって生じる非常に直感に反する振る舞いにも直面します。一部のベンダーは、すべての障害が抽象化された幻想的なプラクティスを販売するために、物事をシンプルで簡単に保つという欲望を利用しています。残念ながら、これらの障害は単なる技術的な問題ではありません。これらの障害こそが、サプライチェーンに実際に機能する可能性のあるものを定義しています。不確実性は、数値的な観点から受け入れられる必要があります。サプライチェーン管理も不確実性を認識し、受け入れる必要があります。

インターンに信頼を置く

サプライチェーンの改善が会社にとって重要であれば、その取り組みにはトップレベルの管理者の直接的な関与が必要です。多くの場合、企業は改善のアイデアを大切にしていますが、その後、インターンなどに課題を任せてしまいます。私たちは非常に優秀なインターンに出会ったことがありますが、インターン主導のサプライチェーンの取り組みが成功した例はありません。もちろん、私たちはインターンに対して何の意見もありません。彼らは優秀で、意欲的で、斬新な考えを持つことがあります。しかし、彼らは会社のサプライチェーンに変革をもたらすために必要なものではありません。サプライチェーンの改善を実行するためには、トップレベルのサプライチェーン管理からのコミットメントが必要です。チームは通常、ほとんど自由な時間を持っていません。現在の取り組みが優先事項であることを、直接的な関与を通じて明確にすることがなければ、現在の取り組みは、貧弱なインターン以外の誰にとっても優先事項ではありません。

計画による死

経営陣は保証を求めます。そして、保証として最も良いのは、明確に定義されたフェーズ、役割、成果物を持つ堅固なロードマップです。しかし、ソフトウェアの歴史が教えてくれたことは、事前に定義された計画は通常、取り組みの最初の週を生き残ることはありません。場合によっては、最初の日さえ生き残れません。サプライチェーンの最適化に関しては、予期せぬことが起こり続けるでしょう。これは、いくらか恐ろしい展望です。しかし、正確な計画によって取り組みを硬直化させることは、問題が予期せぬ問題に対してさらに脆弱になる原因となります。代わりに、取り組みは未知の事象に対してできるだけレジリエントにするべきです。問題からの回復能力は、問題を事前に排除する能力よりも重要です。したがって、サプライチェーン管理は、計画よりもアジャイルな取り組みに焦点を当てるべきです。

予測と最適化の切り離し

サプライチェーンの最適化に関する従来の視点では、予測プロセスと意思決定プロセスを切り離しています。これは、予測と最適化のために2つの異なるアルゴリズムセットを使用するという非常に技術的な観点からは実現可能ですが、機能的な観点からは、予測を担当するチームが最適化も担当する必要があります。実際には、意思決定ロジック、つまり最適化は、予測ロジックに対して数値的に非常に敏感です。2つの視点を分離することは、予測レベルで既に存在する欠陥を拡大し、結果として意思決定に混乱を引き起こします。最適化ロジックは、予測ロジックの強みと弱点とでできるだけ協力的であるべきです。

ソフトウェアのフランケンシュタイン化

大企業で合意を得ることは難しいです。その結果、サプライチェーンに関与する利害関係者の大多数が特定のベンダーを選ぶことを決定する一方で、少数の人々は自分たちのビジョンを強制したり、まったく異なる製品の特定の機能を選択したりすることがあります。ソフトウェアのカスタマイズは大きなソフトウェアベンダーにとって利益を生むビジネスですので、ベンダーは頻繁にこれに応じることがあり、それによってコストと認識される価値を膨らませます。しかし、良いソフトウェアを作るには数年かかりますし、正しく行われた場合、最終結果は対立する目標の微調整のトレードオフを表しています。大企業によるソフトウェアの過剰カスタマイズのほぼシステマティックな結果は、製品の元々の特性を奪い、それによってそれをより良くするのではなく、むしろ悪化させることです。ソフトウェアベンダーには不足していません。解決策が会社に合わない場合は、別のベンダーを選択してください。もしベンダーが会社に合わない場合は、おそらくあなたのビジネスは本当にユニークです - これは珍しいことです - または要件を見直す必要があるかもしれません。

バズワード主導のイニシアチブ

2010年頃、小売業界では天気予報を活用して需要予測を洗練させる方法を見つけることが大流行しました。2012年には、ソーシャルメディアのデータを需要予測に組み込むことが大流行しました。2014年にはビッグデータが主流となり、2016年には機械学習に取って代わられました。年々、新しいバズワードの波がやってきます。古い問題を新しい視点で再評価することにはあまり害はありませんが、むしろ逆です。しかし、コアの課題を見失うことは、既に進行中のイニシアチブを危険にさらすほぼ確実な方法です。あまりにも良いと思えるものは、おそらく実現不可能です。サプライチェーンの改善は困難です。導入したい新しい要素が、本当にサプライチェーンが直面しているコアの課題に焦点を当てていることを確認してください。

ITの実行の悪さ

ITはプロジェクトの失敗の責任を負わされることが非常に多いです。ITは難しいです - IT以外の人々が実際には理解していないほど難しいです。しかし、時にはITチームが善意からプロセスを通じて摩擦を生み出しすぎてしまい、その結果、他の部署が諦めるまでイニシアチブが遅延することがあります。ITチームは一般的な意味での変化だけでなく、将来のポジティブな変化を損なわない特定の種類の変化も受け入れる必要があります。言うは易し行うは難しです。

ITの防御メカニズムに注意

過去に何度か企業のプロジェクトが失敗したとき、ITチームは何度もスケープゴートにされたように感じたかもしれませんので、彼らは特定の「防御メカニズム」を開発しているかもしれません。最も一般的な防御メカニズムの1つは、新しいイニシアチブごとに詳細な仕様書を要求することです。しかし、ソフトウェアソリューションの具体的な仕様を定めることは、ソフトウェアソリューションを実際に実装するよりも難しい傾向があります。その結果、これは複雑な問題をさらに複雑な問題に置き換えることになります。他の防御メカニズムには、次のような厳格な「要件」があります。ソフトウェアはオンプレミスに配置されるべきであり、ソフトウェアはXYZと互換性があるべきであり、ソフトウェアには特定のセキュリティ機能が必要です。良いソフトウェアを作るには数年かかります。要件の長いリストが書かれた後、通常は2つのタイプのソフトウェアベンダーしか残りません。要件と互換性がないベンダーと、要件と互換性があると偽るベンダーです。

データの努力を過小評価する

これは矛盾しているように思えるかもしれませんが、サプライチェーンの取り組みは、ITが解決策を考案する際に過度に関与し、データの準備を自ら行うことで失敗する場合もあります。実際、ITは非常に複雑であり、非常に才能のある人々を含んでいるため、一部のITチームは他の企業のビジネスをよりよく知っていると考えるようになることがあります。この考え方の主な望ましくない結果は、企業データを扱う際に関わる課題を常に過小評価してしまうことです。意味のある方法でデータを処理することは、データを行き来させることではありません。むしろ、このデータが企業のプロセスやワークフローをどのように反映しているかを微妙に理解することです。また、企業システムで発生するデータの微妙な変化、バイアス、制約を理解することも重要です。ITチームがデータの準備を引き継ぐことは、元々のビジョンに欠けていた深さに徐々に気付くため、予期せぬ遅延を引き起こす確実な方法です。これらすべてを考慮に入れると、合理的な選択肢は、この役割をIT部門の外部の誰かに事前に委任することです。

拡張可能なプラットフォームの誘惑

エンタープライズソフトウェアに関しては、ベンダーが習得していることがあります。それは、多くのモジュールを備えた「拡張可能な」プラットフォームであり、これらのモジュールは多くのアップセルの機会を表しています。しかし、プラットフォーム同士はうまく連携しませんし、会社内で同じ機能を競合する2つのプラットフォームがすぐに現れます。2つの重複するプラットフォームは、どの会社にとってもITの悪夢であり、通常、設定が難しく、さらに保守が困難な同期メカニズムに結果的になります。したがって、包括的な解決策を選択することは誘惑されるかもしれませんが、合理的な選択肢はほとんど常に、1つのことをうまく行う狭いアプリケーションを選択することです。数十もの狭いアプリケーションを維持することは簡単ですが、同じくらい大きな機能の重複を持つ2つの大規模なプラットフォームを管理することは地獄です。

信頼性のないデータ抽出

データは量的なサプライチェーンの取り組みにとって血液のような存在です。ポンプを止めると、それは死んでしまいます。この取り組みは常に新鮮なデータで供給される必要があります。しかし、ITはしばしば一度だけのデータ抽出を行うことで十分だと考えています。結局のところ、この取り組みはすぐに終了する可能性が高いため、この初期のデータ抽出段階であまり努力をする意味はほとんどありません。しかし、この考え方に従うと、信頼性のあるデータ抽出のための自動化プロセスの実装が遅れ、その結果、取り組み自体の失敗の主な原因の1つとなります。ここで、ITは積極的になり、データ抽出のための自動化を一日目から開始する必要があります。さらに、ITチームは、この追加の努力が取り組みの主要な成功要因であり、使い捨てのデータ抽出オプションはどこにもつながらないことを他の会社に説得する役割も果たす必要があります。

悪い数値レシピ

サプライチェーンの最適化は、主に数値のゲームです。もちろん、会社のビジョンは重要ですし、リーダーシップも重要ですし、規律も重要ですが、私たちの経験からは、ほとんどの企業はこれらの領域で十分な仕事をしていると言えます。しかし、数値に関しては、サプライチェーンの取り組み全体が悪い数値レシピによって乗っ取られているように見えます。すべての数式やモデル（ここでは数値レシピと呼ぶ）が、かなり厳格な仮定に依存していることを、すべてのサプライチェーンの実践者が認識しているわけではありません。仮定のいずれかを破ると、数値レシピは崩壊します。このセクションでは、この点で最も一般的な違反事項をリストアップします。簡潔さのために、読者が既にレシピ自体に精通していると仮定します。

ABC分析

ABC分析は、サプライチェーンを推進するためのオプションとしてコンピュータが利用できなかった時代に考案されました。ABC分析の主な利点は、分析を非常にシンプルに保つことで、手作業で行うことができるということです。しかし、現代のコンピュータの処理能力を考えると、ABC分析を使用することはもはや意味がありません。数千ものSKUを3つまたは4つの任意のクラスに分類することにはゼロの利益がありません。最も多く販売される商品と非常に長いテールの商品の間には完全な連続性があります。サプライチェーンを最適化するロジックは、この連続性を受け入れるべきであり、最初からこの連続性が存在しないと否定するべきではありません。実際には、市場の変化によってクラスの不安定性が生じ、製品が時間とともにクラスを変更するというネガティブな影響も観察されています。

安全在庫

倉庫には「安全在庫」というものはありません。安全在庫は、在庫を作業在庫と安全在庫の2つのカテゴリに分ける架空の概念です。歴史的な観点から見ると、安全在庫は需要の変動やリードタイムの変動に対処するための単純な方法として導入されました。安全在庫は正規分布（ガウス分布とも呼ばれる）に基づいてモデル化されます。しかし、ほとんどのサプライチェーンのデータセットを見れば、需要もリードタイムも正規分布に従っていないことが明らかです。1980年代初頭、コンピュータの処理速度が非常に遅かった時代には、正規分布は複雑さと精度のトレードオフとして妥当な選択肢であったかもしれませんが、現在では、初期のコンピュータの制約に対処するために設計されたものを保持する意味はありません。

手動予測修正

一部の実践者は、システムが生成できる予測よりも優れた予測を「打ち負かす」ことができることを自慢するかもしれません。もしそうであるならば、システムは不正常であり、通常は実践者の経験と洞察を活用して修正する必要があります。大規模なサプライチェーンを最適化するには、1日に数千、数百万の予測を生成する必要があります。サプライチェーンチームからの手動データ入力に頼ることは、会社にとって有効なオプションとは考えられません。過去20年間の統計学の進歩を考えると、同じデータ入力が与えられた場合、自動化システムが毎回数秒しか費やすことができない人間よりも優れたパフォーマンスを発揮できない理由はありません。もし人間が会社が行うすべての意思決定に数日を費やす時間があるのであれば、状況は根本的に異なるでしょう。しかし、サプライチェーンが日常的に行うほとんどの意思決定はこのカテゴリには当てはまりません。

アラートと悪い予測のモニタリング

古典的な予測は、一つの未来に焦点を当てたものであり、平均値や中央値を目指す予測です。しかし、未来は不確実であり、予測は最善の場合でも概算に過ぎません。特定の状況では、古典的な予測はまったく間違っています。これらの大きな予測誤差のために、通常企業は莫大なコストを負担しています。その結果、これらの大きな誤差を追跡するためにアラートが設置されます。しかし、主な原因は予測そのものではなく、古典的な予測の視点です。古典的な予測は一つの未来に焦点を当てており、すべての未来が可能であるにもかかわらず、等しく確率的に起こるわけではありません。確率的予測の視点からは、予測誤差は事前に主に既知であり、確率の分布として表されます。これらの確率は、可能な値の幅広い範囲に細かく広がっています。確率的予測は、不確実性の度合いが高い場合に、企業が供給チェーンの活動を積極的にリスク回避するアプローチを重視します。一方、古典的な予測にアラートを設定することは、不確実性を否定する設計上の問題の症状です。

過去データの修正

過去データに在庫切れやプロモーションなどのバイアスがある場合、そのバイアスを修正して過去データを修正することで、データがバイアスなしの状態で反映されるようにすることは誘惑されるものです。これを「過去データの修正」と呼んでいます。過去データの修正の基本的な考え方は、すべての予測モデルが移動平均のバリエーションとして設計されているということです。もし移動平均しか持っていないのであれば、確かに過去データを移動平均に合わせるために調整する必要があります。しかし、過去データの修正は解決策ではありません。実際には、解決策は展望を広げ、移動平均のように機能しないより良い予測モデルを探すことにあります。より良い統計モデルは、「豊かな」過去データの処理に成功するために使用されるべきであり、バイアス自体もデータの入力として扱われるべきです。このような統計モデルは数十年前には利用できなかったかもしれませんが、今では利用できるようになっています。

リードタイムの二級市民化

なぜかわかりませんが、リードタイムは頻繁に単なるデータ入力として考えられることがあります。将来のリードタイムは不確実であり、ほとんどの場合、将来のリードタイムを信頼性のある方法で推定するためには、過去に観測されたリードタイムを使用するのが最善の方法です。したがって、リードタイムには独自の予測が必要です。さらに、正確なリードタイムの推定の供給チェーンへの影響は、多くの実務家が認識している以上に大きいです。在庫に保持される数量は、特定のリードタイムの需要をカバーするために存在しています。リードタイムを変更すると、在庫数量も変化します。したがって、リードタイムの予測は、供給チェーンの取り組みにおいて二級市民の役割を与えることはできません。ほとんどの供給チェーン計画は正確な需要予測の必要性を強調していますが、私たちの経験からは、実際には正確なリードタイムの予測も同じくらい重要です。

疑似科学

疑似科学は科学の特徴を備えています。合理的に感じ、数字があり、証明されているとされ、非常に教養のある人々がその主張を擁護しています。しかし、疑似科学は繰り返し可能な結果を達成するテストに耐えることができません。通常、疑似科学を検出するためには実験の設定さえ必要ありませんし、疑似科学の材料は公平な専門家の査読の厳しい目の前で崩れ始めます。サプライチェーンは運営コストが高く、理解するのが複雑です。これらの2つの特性だけで、サプライチェーンの方法論がかなりの難しさを持つ理由が説明されます。実験には多くのリスクが伴うだけでなく、どの要素が実際に改善に貢献しているのかを正しく評価することも難しいからです。

空想的なビジネスケース

サプライチェーンのソリューションは、ベンダーが大胆な主張をする唯一のエンタープライズソフトウェアの領域ではありませんが、古い言葉によれば、「あまりにも良すぎるように見える場合、それはおそらくそうではない」と言われています。私たち自身も、世界最大の小売貿易ショーであるニューヨークのNRFトレードショーで、ほぼ毎年1月に開催されるイベントで、非常に大きなベンダーが登場し、彼らの新しいソリューションの助けを借りて在庫レベルを半分にできると大胆に主張しているのを目にします。もしもそれらの主張の1割が本当だったら、10年前には業界全体がほぼ完璧な在庫レベルを達成していたはずです。ビジネスケースの数字を操作する方法はたくさんありますので、ほとんどのベンダーは実際には嘘をついているわけではありません。最も一般的なケースは、ソリューションの「模範的な事例」として宣伝されている企業が、元々大規模な機能不全を抱えたサプライチェーンを持っていたため、事態が1年後に正常に戻った後、同様に大幅な改善が可能であったということです。

予測には営業チームを信じる

営業チームに正確な需要予測数を作成するように依頼する人々が、実際に営業チームと一緒に働いたことがあるのかどうかは謎です。最良の場合、これらの数字は正直な推測と見なされるかもしれませんが、ほとんどの場合、営業チームが与えられた財務的なインセンティブを利用して作り上げたものです。これにより、広く行われている「サンドバッギング」という慣行が生まれます。すべての人が期待値を超えるために、目標をできるだけ低く設定します。さらに、供給チェーンチームは、営業チームが提供した情報に基づいて実際の運用を行っていると見せかけることがよくありますが、実際の運用は営業チームが示唆する数字とは全く別のものです。営業チームが示唆する数字を無視することは、供給チェーンにとって唯一の合理的な選択肢です。なぜなら、もしも供給チェーンが実際にそんなに悪い数字に基づいて運用しなければならないなら、それはまったく機能しなくなるからです。

証明されたソリューション

あなたの会社と非常に似た状況の会社に実際に利益をもたらした証明されたソリューションを探すことは、非常に合理的な視点のように思えるかもしれません。逸話的な観点から言えば、これはノキアが行ったことであり、他の無数の企業も同様ですが、それがなくなるまでの間には非常に速く行動する大企業はほとんどありません。ベンダーの選択プロセスは最大で1年かかることがあります。選択したソリューションでのクルージングスピードの達成にはさらに1年かかるかもしれません。結果に対するモニタリングと信頼を得るには、さらに1〜2年かかる場合もあります。特にすべてのソリューションが持続可能ではないサプライチェーンでは、ベンダーが常に現地にいてソリューションを微調整できなくなったら、サプライチェーンはすぐに以前のパフォーマンス状態に戻る可能性があります。その後、ソリューションベンダーがこの苦労して得た証拠を最終的にあなたの会社に届けるまでにはさらに1年かかるかもしれません。この考え方の致命的な欠陥は、あなたの会社が5年遅れても問題ないということです。ソフトウェアの場合、5年は非常に長い時間です。ほとんどのソフトウェアは実際には5年で時代遅れと見なされます。なぜなら、あなたのサプライチェーンソリューションが異なると考えるべきではないからですか？

悪いメトリクス、悪いベンチマーク

量的なサプライチェーンは、信頼できる数字に関するものです。その結果、私たちはメトリクスとベンチマークに非常に傾倒しています。しかし、サプライチェーンでは、ほとんどのベンチマークとメトリクスが非常に悪く設計されているため、私たちの本では一般的に疑似科学と見なされています。良いサプライチェーンのメトリクスには多くの努力が必要です。良いサプライチェーンのベンチマークには、ほとんど狂気じみた努力が必要です。あまりにも簡単なタスクとしてベンチマークを運用する場合、それは課題が大幅に過小評価されている可能性があります。