供給チェーンにおけるアンチパターン

サプライチェーンの取り組みはしばしば失敗します。量的サプライチェーンは、失敗率を劇的に下げるための私たちの解答です。しかし、量的サプライチェーンは効果があると分かっている慣行に焦点を当てるため、効果がないと分かっている慣行にはほとんど重点を置いていません。さらに悪いことに、これら望ましくない慣行のほとんどが、伝統的なサプライチェーン手法に伴う高い失敗率の根本原因であることが判明しています。

以下に、ほとんどのサプライチェーンの取り組みを失敗に導く慣行、すなわちパターンを見直します。これらの洞察は苦労して得たものであり、各洞察を得るためには通常、失敗を一度ではなく複数重ね、問題の根本原因を把握する必要がありました。私たちはこれらの有害な慣行を サプライチェーン・アンチパターン と呼んでいます。アンチパターンとは裏目に出る「解決策」であり、一般的なアプローチであって、良いアイデアに思えながらも、最初に目指された改善を確実に達成できないものです。

悪いリーダーシップ

Lokadでは、主要なサプライチェーン決定者を敵に回したくはありません。彼らは私たちの見込み客であり、クライアントです。しかし同時に、設計上失敗が必至な解決策に基づく取引を成立させることを拒否するのは我々の義務だと考えています。しばしば問題の根源は、取り組み自体の管理方法に帰着します。とはいえ、サプライチェーン管理が唯一の犯人であるとは認識していません。特定のベンダーは時としてクライアントに誤ったメッセージを送り、遠慮なくそれを実行に移しています。旧態依然とした慣行や社内政治も、サプライチェーン管理の日常を蝕み、物事が意図通りに進まない際の罪のなすりつけ対象となる可能性があります。このセクションでは、見直されたサプライチェーンリーダーシップによって対処できる一般的な落とし穴を列挙します.

地獄からのRFQ

RFQ（見積依頼）が有効な分野は多々あるかもしれません。残念ながら、ソフトウェアはその一つではありません。ソフトウェアの仕様書を書くことは、ソフトウェアそのものを書くよりもはるかに困難です。その作業は大変なものです。一旦RFQプロセスに入ると、企業はコンサルタントを導入して、既に複雑すぎる仕様書をさらに複雑にしてしまい、状況を悪化させます。RFQは問題解決のための思考を抑制します。なぜなら、RFQプロセスはクライアントが既に望む解決策の細部を知っていると仮定する一方で、「問題」はRFQ作成時点では本質的にほとんど未解決であるためです。さらに実際には、RFQは対立的なベンダー選定プロセスを促進し、優れたベンダーは去り、劣るベンダーが残る結果となります。最後に、ソフトウェア業界は非常に変化が速く、貴社がRFQプロセスを終える頃には、競合他社が既に自社の解決策を展開していることでしょう.

脆弱なPOC

POC（概念実証）の実施は、購入しようとしているものが例えば名刺用の印刷サービスのような、ほぼ商品化されたシンプルなサービスである場合には有効です。しかし、サプライチェーンの取り組みは設計上複雑です。サプライチェーンは複数の組織間の連携を必要とし、活用すべき多層のデータが存在し、考慮すべき数多くのワークフローがあります。POCや小規模なパイロット実験は、成功するサプライチェーンの基本的な美徳、すなわち大規模運用の能力を無視するという設計上の欠陥から、功を減らす結果となります。多くの人々は規模の経済の原則に慣れ親しんでいますが、サプライチェーンの最適化では、むしろ逆に、問題の複雑性が増すにつれて良い判断がどんどん難しくなる非経済性に直面することがほとんどです。小さな配送センターで成功したとしても、その解決策が数十もの異なる配送センターにおいても同様に機能する保証は全くありません.

不確実性の軽視

未来は不確実であり、不確実性は望むだけで消えるものではありません。同様に、サプライチェーンの数値最適化も、望むだけでは解決しない困難な問題です。サプライチェーンの最適化には、不確実な未来に対処する直接の結果として生じる確率的予測が必要です。さらに、サプライチェーン最適化は数値最適化によって生み出される、直感に反する振る舞いにも直面します。一部のベンダーは、すべての障壁が抽象化されるという幻想的な実践を売り込むために、物事をシンプルかつ容易に保ちたいという欲求を利用します。残念ながら、これらの障壁は単なる技術的な問題ではなく、実際にサプライチェーンが機能する可能性を定義するものです。不確実性は、深い数値的視点から受け入れられるべきです。サプライチェーン管理も、不確実性を認め、受け入れる必要があります.

インターンを信頼する

貴社にとってサプライチェーンの改善が重要であるならば、その取り組みにはトップマネジメントの直接関与が必要です。あまりにも頻繁に、企業は改善という考えを大切にしながらも、結局はインターンを一人二人この案件に割り当てるだけです。私たちは非常に有能なインターンに出会ったことはありますが、インターン主導のサプライチェーン改善の取り組みが成果を上げたのを見たことは一度もありません。決してインターン自体を否定するわけではありません。彼らは賢く、意欲的で、常識にとらわれない発想ができるかもしれませんが、サプライチェーンに変革をもたらすために必要な存在とは程遠いのです。トップレベルのサプライチェーン管理者からのコミットメントは当然必要であり、そうでなければチームは実行に移せません。チームは通常、余裕のある時間を持っていません。経営陣が直接関与することで現在の取り組みが最優先事項であると明確に示さない限り、現状の取り組みは実際には誰にとっても優先事項ではなく、ひょっとするとその案件に割り当てられた可哀そうなインターンだけの優先事項になってしまいます.

計画による死

経営陣は安心感を求め、その安心感を得るためには、明確なフェーズ、役割、成果物が定義された堅固なロードマップに敵うものはありません。しかし、ソフトウェアの歴史が教えてくれるのは、事前に定義された計画は通常、取り組み開始から一週間もたたないということです。場合によっては初日をも乗り越えられないこともあります。サプライチェーンの最適化においては、予期せぬ事態が次々と発生し、これは非常に恐ろしい状況です。しかし、精密な計画によって取り組みを硬直化させると、予期せぬ問題に対してなお一層取り組みが脆弱になってしまいます。むしろ、取り組みは未知の状況に対してできる限りレジリエンスを持つようにすべきです。問題からの回復力は、あらかじめ問題を完全に排除する能力よりも重要です。したがって、サプライチェーン管理は、良く計画されたものよりも柔軟に対応できる取り組みの構築に注力すべきです.

予測と最適化の切り離し

従来のサプライチェーン最適化の見方では、予測プロセスと意思決定プロセスが分離されています。これは、予測用と最適化用という二種類のアルゴリズムを用いるという非常に技術的な観点からは実現可能ですが、機能的な観点から見ると、予測を担当するチームが最適化も担当しなければなりません。実際、意思決定のロジック、言い換えれば最適化は、数値的に予測のロジックに非常に敏感です。これら二つの視点を分離することは、予測レベルで既に存在するかもしれない欠陥を増幅し、その結果、意思決定に混乱を招く原因となります。最適化のロジックは、予測のロジックの強みと弱みとできる限り協調する形で数値的に構築されるべきです.

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

大企業では合意を形成するのが困難です。その結果、サプライチェーンに関与する大多数のステークホルダーが特定のベンダーを選択する一方で、少数派は自らのビジョンを押し通すか、あるいは全く別の製品の特定の機能を選びたがることがあります。ソフトウェアのカスタマイズは大手ソフトウェアベンダーにとって利益を生むビジネスであるため、ベンダーは費用や評価価格を膨らませながらも喜んで応じることが多いのです。しかし、良いソフトウェアの開発には何年もかかり、正しく作り上げられた最終成果は、相反する目標間の絶妙なトレードオフを示します。大企業によるソフトウェアの過度なカスタマイズのほぼ体系的な結果は、製品本来の特性を奪い、改善するどころか、層を重ねることでかえって悪化させ、まるで怪物のようにしてしまうのです。ストックアウトのソフトウェアベンダーは存在しません。もしその解決策が貴社に適していなければ、次に進んで別のベンダーを選ぶべきです。どのベンダーも貴社に適合しない場合は、貴社のビジネスが本当にユニークであるか（これは稀ですが）、もしくは要求事項を見直すべきでしょう.

バズワードに駆動された取り組み

2010年頃、小売業界では天気予報を活用して需要予測を洗練する方法が大流行しました。2012年にはソーシャルメディアのデータを需要予測に組み込むのが流行し、2014年にはビッグデータが支配的となり、2016年には機械学習に取って代わられました。年々、新たなバズワードが登場します。新たな視点で古い問題に再挑戦すること自体には特に害はありませんが、むしろ、主要な課題を見失うことは、既に進行中の取り組みを危険にさらす確実な手段と言えます。あまりにも良すぎる話は、おそらく実現しないのです。サプライチェーンの改善は苦労して得たものです。あなたが導入したいと考える新奇なアイデアが、実際にサプライチェーンが直面する核心的な課題に焦点を当てていることを確認してください.

悪いIT実行

プロジェクトの失敗の責任が度々ITに押し付けられます。ITは非常に難しく、IT以外の人々が考える以上に困難です。しかし、善意からか、ITチームがそのプロセスを通じてあまりにも多くの摩擦を生み出し、結果として会社全体が投げやりになるほど取り組みが遅れることもあります。ITチームは、一般的な変化だけでなく、将来の好ましい変化を損なわない特定の変化も受け入れる必要があります。言うは易く行うは難しです.

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

過去にいくつかの企業プロジェクトが失敗した際、ITチームがスケープゴートにされた経験から、特定の「防衛メカニズム」を身につけた可能性があります。最も一般的な防衛メカニズムのひとつは、あらゆる新規取り組みに対して詳細な書面による仕様書を要求することです。しかし、ソフトウェアの解決策を仕様化することは、実際の実装よりも困難である傾向があります。その結果、複雑な問題をさらに複雑な問題に置き換えることになってしまいます。他の防衛メカニズムとしては、「ソフトウェアはオンプレミスに配置すべき」、「ソフトウェアはXYZと互換性があるべき」、「ソフトウェアは特定のセキュリティ機能を有すべき」など、厳格な「要求事項」を掲げることがあります。良いソフトウェアの開発には何年もかかります。要求事項の長いリストが完成すると、通常、残るソフトウェアベンダーは二種類に分かれます。すなわち、要求に対応できないものと、要求に対応できると偽るものです.

データ作業の過小評価

一見矛盾しているように思えるかもしれませんが、サプライチェーンの取り組みは、ITが解決策の立案に過度に関与し、データの準備まで自ら引き受けるために失敗することもあります。実際、ITは非常に複雑であり、有能な人材が含まれていることもあるため、あるITチームは会社内の他の部署以上にビジネスを理解していると考え始めるかもしれません。この考え方の主な望ましくない結果は、企業データに関わるあらゆる作業の難しさを常に過小評価してしまう点にあります。意味のあるデータ処理は、単にメガバイト単位のデータを移動することではなく、このデータが企業のプロセスやワークフローをどのように反映しているかを微妙に理解することにかかっています。また、データが企業のシステム内でどのように微妙なずれ、偏り、限界を持っているかを理解することも含まれます。ITチームがデータ抽出パイプラインを引き受けることは、当初のビジョンに欠けていた深みを徐々に実感するため、予期せぬ遅延を招く確実な方法です。これらを踏まえると、合理的な選択肢は、この役割を最初からIT部門以外の誰かに委任することです.

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

エンタープライズ向けソフトウェアにおいて、ベンダーが極めて熟練していることがあります。それは、多くのモジュールを備えており、多くのアップセル機会をもたらす「拡張可能な」プラットフォームであるという芸術です。しかし、プラットフォーム同士はうまく連携せず、社内で同じ機能を内部競合する二つのプラットフォームという機能重複がすぐに現れます。二つの重複するプラットフォームはどの企業にとってもITの悪夢となり、通常は設定が難しく、維持管理がさらに困難な同期機構を生み出します。したがって、包括的なソリューションに走る誘惑にかられても、合理的な選択肢はほとんどの場合、一つのことに特化し、それを確実に実行する狭いアプリケーションを選ぶことにあります。数十もの狭いアプリケーションを維持するのは簡単ですが、同程度に大きな機能重複を持つ二つの大規模プラットフォームを管理するのは地獄です.

信頼性の低いデータ抽出

データは定量的サプライチェーン・イニシアティブにとって血液のようなものであり、供給が止まれば枯れてしまいます。このイニシアティブは常に新鮮なデータを供給される必要があります。多くの場合、IT部門は物事を始めるために数回の一度限りのデータ抽出で十分だと考えがちです。結局のところ、ほとんどのサプライチェーン・イニシアティブが失敗することを思い出せば、このイニシアティブがすぐに終了する可能性が高いのですから、初期のデータ抽出段階で過度の努力を投資する意味はあまりありません。しかし、この考えに従うと、信頼性のあるデータ抽出を自動化するプロセスの実装が遅れてしまい、その結果、イニシアティブ自体の失敗の主要な原因の一つとなってしまいます。ここで、IT部門は初日から積極的にデータ抽出の自動化を開始すべきです。さらに、ITチームは、この追加の努力がイニシアティブの成功の鍵であり、使い捨てのデータ抽出方法では何も得られないと会社全体を説得するための指導的役割も担っています。

悪い数値レシピ

サプライチェーンの最適化は、主に数字のゲームです。当然、企業のビジョン、リーダーシップ、規律も重要ですが、私たちの経験では、ほとんどの企業はこれらの分野で十分以上の成果を上げています。しかし、数字に関しては、サプライチェーン全体が悪い数値レシピに支配されているように見えます。すべてのサプライチェーン実務者が認識しているわけではありませんが、ここで言う数値レシピと呼ばれるすべての数式やモデルは、かなり厳格な前提に依存しています。前提の一つでも破られれば、その数値レシピは崩壊してしまいます。このセクションでは、その点でよく見られる問題点をリストアップします。簡潔さのため、読者がすでにこれらのレシピに精通しているものと仮定します。

ABC分析

在庫に対するABCアプローチは、コンピューターがサプライチェーンを推進する手段として利用できなかった時代に考案されました。ABC分析の主要な利点は、分析が非常にシンプルで手作業でも実施できる点にあります。しかし、現代のコンピューターの驚異的な処理能力を考えると、今日においてABC分析を用いる意味はもはやありません。数千ものSKUを3あるいは4の恣意的なクラスに分類することに、何の利点もありません。最もよく売れる製品から非常に売れ行きの少ない製品に至るまで、連続的な違いが存在します。サプライチェーンを最適化する論理は、この連続体を受け入れるべきであり、そもそもその連続体の存在を否定すべきではありません。実際、市場の変動によりクラスが不安定になり、製品が時間とともにクラスを変え続けることで、ABC分析の悪影響はさらに深刻化することが観察されています.

安全在庫

あなたの倉庫には「安全在庫」というものは存在しません。安全在庫は、手元在庫を作業在庫と安全在庫の2つに分けるという架空の概念です。歴史的な観点から見ると、安全在庫は変動する需要やリードタイムに対処するための単純な手法として導入されました。安全在庫は、正規分布（ガウス分布とも呼ばれる）に基づいてモデル化されています。しかし、ほとんどのサプライチェーンデータセットをざっと見渡すだけでも、需要もリードタイムも正規分布していないことは明らかです。1980年代初頭、コンピューターが非常に遅かった時代には、正規分布は複雑さと予測精度との間の妥協策として有効だったかもしれませんが、現在では初期コンピューターの制約に対処するための「ハック」として設計されたものに固執する理由はありません。

手動による予測の修正

一部の実務者は、「システムを打ち負かし」、システムが生成する数値よりもより良い予測を生み出せると自負しているかもしれません。もしそれが実際に事実であれば、そのシステムは機能不全と見なされ、実務者の経験と洞察を活かして修正されるべきです。大規模なサプライチェーンの最適化には、1日に何千、いや何百万もの予測を生成する必要があります。サプライチェーンチームによる手動のデータ入力に頼ってシステムの欠陥に対処することは、企業にとって有効な選択肢とは言えません。過去20年間の統計学の進歩を考えれば、同一のデータ入力が与えられた場合に、自動化システムが、現実的に言えば各数値の計算に数秒しか割けない人間を上回るという理由は全くありません。もし人間が企業の意思決定ごとに数日を費やすことができれば状況は大きく変わるでしょう。しかし、サプライチェーンの日常的な多数の意思決定はそのような余裕があるものではありません.

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

古典的な予測は、平均値または中央値を目指す1つの未来に重点を置き、あたかもその1つの未来が意味ある確率で実現するかのように扱います。しかし、未来は不確実であり、予測はせいぜい概算に過ぎません。場合によっては、古典的な予測は完全に誤っていることもあります。その大きな予測誤差によって、企業はしばしば莫大なコストを負担することになります。その結果、これらの大きな誤差を追跡するためにアラートが設定されるのです。しかし、主要な問題は予測そのものではなく、すべての未来が可能であるにもかかわらず、一つの未来のみを強調する古典的な予測の視点にあります。確率的予測の観点からは、予測誤差はあらかじめ把握され、可能な値の広範な範囲にわたって細かく分布する確率分布として表されます。確率的予測は、不確実性が高い状況に対応する際に、企業が積極的にサプライチェーンのリスクを低減するアプローチを強調します。対照的に、古典的な予測にアラートを設定することは、設計上根本的に欠陥のあるアプローチの症状であり、不確実性全体を否定しているに過ぎません.

過去データに応急処置を施す

在庫切れやプロモーションなどのバイアスが過去データに見られる場合、そのバイアスを「修正」して、バイアスがなかった場合の履歴をより正確に反映させようとする誘惑に駆られます。このプロセスを、過去データの「ダクトテープ処理」と呼んでいます。ダクトテープ処理の基本的な考え方は、すべての予測モデルが移動平均の変形として設計されているというものです。もし手元に移動平均しかなければ、確かに過去データはこれらの移動平均を補正するために調整される必要があります。しかし、ダクトテープ処理は解決策ではありません。実際の解決策は視野を広げ、移動平均ほど機能不全でない、より良い予測モデルを探すことにあります。バイアス自体をデータ入力として取り扱う「強化された」過去データをうまく扱うためには、より優れた統計モデルが使用されるべきです。こうした統計モデルが数十年前には存在しなかったとしても、現在ではもはやそうではありません.

リードタイムを二流市民として扱う

私たちにははっきりと理解できない理由で、リードタイムは独自の予測を必要とするものではなく、単なるデータ入力として扱われがちです。将来のリードタイムは不確実であり、信頼性の高い将来のリードタイムを見積もる最良の方法は、過去に観測されたリードタイムを用いることです。したがって、リードタイムにはそれ自体の予測が必要です。さらに、正確なリードタイムの見積もりがサプライチェーンにもたらす影響は、実務者が思っている以上に大きいのです。なぜなら、在庫として保持されている数量は、特定のリードタイムに対する需要をまさに補うために存在しているからです。リードタイムが変われば在庫数量も変動します。したがって、リードタイム予測をサプライチェーンの取り組みの中で二流市民として扱うわけにはいきません。ほとんどすべてのサプライチェーン計画は、正確な需要予測を強調していますが、実際には正確なリードタイム予測も同様に重要であると私たちの経験は示しています.

疑似科学

疑似科学は、科学らしさをすべて備えています。合理的に感じられ、数字が伴い、証明されたとされ、非常に教養のある人々がその主張を支持しています。しかしながら、疑似科学は再現可能な成果を挙げるという試練に耐えません。通常、疑似科学を見抜くために実験のセットアップすら必要なく、偏りのない専門家による厳正なピアレビューのもとで、その資料は次第に崩壊していきます。サプライチェーンは運用に高額なコストがかかり、理解するのが非常に複雑です。この2つの属性だけでも、サプライチェーンの手法が挑戦されにくい理由を十分に説明しています。実験には多大なリスクが伴うだけでなく、何が真に改善に寄与しているのかを正確に評価するのも困難なのです.

空想的なビジネスケース

サプライチェーンソリューションは、ベンダーが大胆な主張を行う企業ソフトウェアの唯一の分野ではありませんが、「良すぎる話は真実ではない」という古い格言があるように、あまりに良さすぎる話はおそらくそうではないのです。私たち自身、創業100年以上の歴史を持つ世界有数の小売見本市であるニューヨークのNRFトレードショーで、ほぼ毎年1月に、大手ベンダーが新たなソリューションの助けを借りて在庫レベルが半分にまで削減できると大胆に主張しているのを目にしています。もしその主張のたった1割が事実であったなら、業界全体は10年前にほぼ完璧な在庫レベルを実現していたことでしょう。ビジネスケースの数値を操作する方法は数多くあり、ほとんどのベンダーは実際には嘘をついていないのです。最も一般的なケースは、ソリューションの「ポスター・チャイルド」として宣伝された企業が、元々非常に機能不全なサプライチェーンを有しており、正常化した1年後に非常に大きな改善数値を達成できたというものです.

予測を営業チームに任せる

正確な需要予測数値の作成を営業チームに任せる人々が、実際に営業チームと共に働いた経験があるのかどうかは謎のままです。最良の場合、これらの数値は正直な推測と見なせるかもしれませんが、ほとんどの場合、営業チームが与えられた金銭的インセンティブを操作するために作り出しただけのものです。これが「サンドバギング」として知られる広範な慣行を生み出し、誰もが後で期待を上回るために目標をできるだけ低く設定する結果となります。さらに、下流では、サプライチェーンチームがこれらの数値に注意を払っているふりをしている一方、実際のオペレーションは営業から提供された数値とは全く無関係に進行しているのが現状です。もし営業チームが提示する数値に基づいてサプライチェーンを運用するならば、サプライチェーンは全く機能してはいけないため、営業チームの数値を無視することが唯一合理的な選択肢となります.

実証済みのソリューション

自社と非常に似た企業に対して、具体的な利益をもたらした実証済みのソリューションを求めることは非常に合理的に思えるかもしれません。逸話的に言えば、これはかつてノキアや他の数え切れないほどの企業が実践していた方法です。しかしながら、多くの大企業は、複雑なソリューションの選定に際してそれほど迅速に行動しません。ベンダー選定プロセスに最大1年がかかることもあり、その後、選定されたソリューションで定常運転状態に達するまでにさらに1年かかる可能性があります。さらに、結果の監視と信頼の構築に1年、あるいは2年が必要となることもあります。特に、すべてのソリューションが持続可能ではなく、ベンダーが現場に常駐してソリューションを微調整しなくなった途端にサプライチェーンがすぐに従来の状態に戻ってしまう場合にはなおさらです。その上、ソリューションのベンダーがこの苦労して得た実績をもって最終的に自社に届くまでにさらに1年かかるかもしれません。この考え方の致命的な欠陥は、貴社がパーティに5年遅れて参加しても構わないと考えている点にあります。ソフトウェアに関しては、5年は非常に長い期間です。実際、多くのソフトウェアは5年目にはすでに陳腐化しているのです。では、なぜ貴社のサプライチェーンソリューションだけが例外であるはずがあるのでしょうか？

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

定量的サプライチェーンは、信頼できる数字に基づくものです。そのため、私たちはメトリクスとベンチマークに大きく依存する傾向があります。しかしながら、サプライチェーンにおいては、ほとんどのベンチマークとメトリクスが非常に不十分に設計されており、私たちの見解では疑似科学と見なされがちです。優れたサプライチェーンのメトリクスには多大な努力が必要であり、優れたサプライチェーンのベンチマークには途方もない努力が求められます。単純さを追求するあまり、メトリクスとベンチマークが簡略化され、その結果、ビジネスにとっての実際の関連性がすべて失われてしまうことがしばしばあります。経験則として、サプライチェーンチームにとってベンチマークの運用が非常に困難な作業でなければ、その課題は大幅に過小評価されている可能性があるのです.