00:00 イントロダクション
03:39 自動化は常に目標でした
06:28 例外管理とアラート
10:27 これまでのストーリー
14:33 今日の製品展開
15:59 要約：成果物、範囲、役割
19:01 意思決定の形を明らかにする
23:00 レガシーに基づく対応
27:20 ゼロパーセントの狂気への反復
32:30 目指すべき指標
36:27 デュアルラン：手動+機械
39:19 分析麻痺
43:21 徐々に自動化を引き継ぐ
46:08 プロセスの堆積
48:57 プランナーからネットワークマネージャーへ
52:46 KPI観光客
54:58 リーダーシップ：コーチからプロダクトオーナーへ
58:46 アナログサプライチェーンのボス
01:02:25 結論
01:04:44 7.2 自動化された意思決定を本番環境に導入する - 質問はありますか？
説明
在庫の補充などの日常的な意思決定を駆動するための数値レシピを求めています。自動化は、サプライチェーンを資本主義の事業にするために不可欠です。ただし、数値レシピが不具合の場合、規模に応じて大きな損害をもたらす重大なリスクがあります。フェイルファストアンドブレイクシングは、数値レシピを本番環境で承認するための適切なマインドセットではありません。ただし、ウォーターフォールモデルなどの多くの代替手段は、通常、合理性と制御の幻想を与えるだけでさらに悪化します。高度に反復的なプロセスが、本番環境で証明された数値レシピの設計の鍵です。
フルトランスクリプト
このサプライチェーンの講義シリーズへようこそ。私はヨハネス・ヴェルモレルで、今日は「自動化されたサプライチェーンの意思決定を本番環境に導入する」を紹介します。過去の2世紀にわたり、私たちの経済は機械化を通じて大きな変革を遂げました。競合他社と比較して優れた機械化度を達成した企業は、ほぼ常にそれらの競合他社を破産に追いやりました。機械化により、より多くのことをより良く、より速く行うことができ、コストを削減することができます。これは、フォークリフトを使用して箱を手で運ぶ代わりに、物品を移動する物理的なタスクにも、銀行に残っているお金の計算などの知的なタスクにも当てはまります。
ただし、タスクを機械化する能力は、技術に依存しています。例えば、ヘアカットやベッドシーツの交換など、まだ機械化できない物理的なタスクは多くあります。逆に、まだ機械化できない知的なタスクもあります。例えば、適切な人材の採用や顧客の要望を把握することです。これらのタスク、知的なものも物理的なものも、いつかは機械化できないという理由はありません。ただし、まだそのような技術は完全には整っていません。
ほとんどの日常的なルーティンのサプライチェーンの意思決定は、現在では自動化されることができます。これは比較的最近の進展です。10年前には、成功裏に自動化できるサプライチェーンの意思決定の範囲は、サプライチェーンの全スペクトルの一部に過ぎませんでした。現在では、適切な技術を使えば、自動化できない反復的なサプライチェーンの意思決定はほとんどありません。私が成功した自動化とは、手動プロセスで得られる意思決定よりも優れた自動化された意思決定のプロセスを指しています。コンピュータで意思決定を生成する能力は、生成された意思決定の品質に関心がない限り、些細なものです。
今日の焦点は、最初にそのような自動化を可能にするソフトウェアの一部である数値レシピではありません。サプライチェーンの意思決定プロセスの文脈では、そのような数値レシピを作成するための要素は、このシリーズの前の章で取り上げられています。今日の焦点は、そのような数値レシピを製品化するために必要なサプライチェーンイニシアチブの一部にあります。この講義の目的は、企業を手動のサプライチェーンの意思決定から自動化のものへ移行するために必要なことを概説することです。この講義の終わりまでに、自動化への移行時に行うべきことと行わないべきことについての洞察を得るはずです。実際、数値レシピ自体に関連する技術的な困難さが、イニシアチブの成功にとって同様に重要な組織的な側面を薄くする傾向があります。
現代のサプライチェーンの実践者が意思決定の自動化のアイデアを提示されると、彼らの即座の反応は「これはまだ未来的なアイデアです。まだそこには到達していません。」となりがちです。しかし、日常的で反復的なサプライチェーンの意思決定の完全な自動化は、デジタル時代のサプライチェーンが始まった40年以上前からの目標でした。
コンピュータが企業で利用可能になるとすぐに、ほとんどのサプライチェーンの意思決定が完全に自動化の候補であることがわかりました。画面上では、この野心を示す出版物のリストを選びました。1970年代と1980年代には、この分野はまだサプライチェーンとは呼ばれていませんでした。その用語は1990年代になってから一般的になりました。しかし、意図は既に明確でした。これらのコンピュータシステムは、在庫の補充などの最も反復的なサプライチェーンの意思決定を自動化するのに適しているとすぐにわかりました。
私にとって最も困惑しているのは、このコミュニティが以前の野望にある程度無頓着なように思われることです。現在では、コンサルティング会社やIT企業が、日常的なサプライチェーンの意思決定の機械化の視点を伝えるために「自律型サプライチェーン」という用語を使用することがあります。しかし、私にとっては「自律型」という用語は不適切です。私たちは、運搬システムを備えたコンベアベルトを「自律型物流」とは呼びません。コンベアベルトは機械化されていますが、自律的ではありません。コンベアベルトにはまだ技術的な監視が必要ですが、このイノベーションは、コンベアベルトなしで商品を運ぶために会社が必要とする労働力のごく一部に過ぎません。サプライチェーンの意思決定に関しては、組織から人間を完全に排除すること、つまり真に自律的な技術を実現することが目標ではありません。目標は、プロセスの最も時間のかかる部分と最も原始的な部分から人間を単に排除することです。これは、40年前に発表された論文で採用された視点であり、私もこの講義で採用している視点です。
1990年代において、ソフトウェアベンダー、ERPベンダー、在庫最適化の専門家などのソフトウェアベンダーは、自動化されたサプライチェーンの意思決定を実現するという考えをほぼ諦めたようです。後になってみると、1970年代の単純化されたモデルは、不確実性など多くの重要な要素を無視していたため、自動化が当時成功しなかった明白な原因でした。しかし、この根本的な原因を修正することは、この時期の技術が提供できる範囲を超えていることがわかりました。その代わりに、ソフトウェアベンダーは例外管理システムにデフォルトしました。これらのシステムは、クライアント企業自体が設定したルールに基づいて在庫アラートを生成することが期待されています。その論理の流れは次のとおりです。自動化によって自動的に処理できる大部分の行に対しては、人間の介入を困難な行、つまり機械の能力を超えた行に集中させるため、自動化によって処理できる行の大部分を処理させましょう。
例外管理システムを販売することは、ソフトウェアベンダーにとって非常に有益な取引ですが、クライアント企業にとってはあまり有益ではありません。まず、例外管理はサプライチェーンのパフォーマンスの責任をベンダーからクライアントに移すものです。例外管理が導入された後、結果が悪い場合、それはクライアントの責任です。最初から損害を防ぐためにより良いアラートを設定すべきでした。
さらに、パラメータ化された在庫アラートを管理するシステムを作成することは、ソフトウェアベンダーにとって簡単です。ただし、ベンダーがソースアラートを制御するパラメータ値を提供する必要がない限りです。実際、分析的な観点から見ると、良い在庫アラートを生成できる能力があるということは、悪い在庫の意思決定を確実に特定できるルールを設計できるということです。悪い在庫の意思決定を確実に特定できるルールを設計できる場合、同じルールを使用して良い在庫の意思決定を確実に生成することもできます。実際、ルールは単に悪い意思決定が行われないようにするためのフィルターとして使用するだけです。
三番目に、例外管理はソフトウェアベンダーが人間の心理を利用するやりかたです。実際、これらのアラートは、実証心理学者によって「コミットメントと一貫性」として知られるメカニズムを利用しています。このメカニズムは、ソフトウェア製品への強力ながら主に偶発的な中毒を作り出します。要するに、従業員が在庫数を微調整し始めると、それはもはや恣意的な数値ではありません。それは彼ら自身の数値、彼らの仕事であり、したがって従業員はシステムに感情的に結びつきます。システムが実際に優れたサプライチェーンのパフォーマンスを提供しているかどうかに関係なくです。
全体的に、例外管理は技術的な行き詰まりです。なぜなら、一般的な場合、信頼性のある例外と信頼性のあるアラートを設計することは、意思決定のための信頼性のある自動化を設計するのとまったく同じくらい困難だからです。アラートや例外に信頼できず、すべてを手動でレビューする必要がある場合、出発点に戻ってしまいます。意思決定プロセスは厳密に手動のままです。
このサプライチェーンの講義シリーズは、二十数話からなります。この時点で、ある意味では、これまで紹介してきたすべての要素は、今日の講義の焦点である量的サプライチェーンイニシアチブを本番環境に導くための明示的な目的で行われてきたものです。具体的には、予測に数値的なレシピを組み込むことを目指しています。
これらの講義では、生の歴史データを入力とし、最終的な意思決定を出力する計算のシーケンスを「数値的なレシピ」という用語で表しています。この用語は意図的に曖昧であり、これまでの章の講義で詳しく説明されたさまざまな概念、方法、技術を反映しています。最初の章では、サプライチェーンがプログラム化される必要性と、このような数値的なレシピを本番環境に導入できることが非常に望ましい理由を見てきました。サプライチェーン自体のますます複雑化により、自動化は以前よりも重要性が高まっています。また、サプライチェーンの実践を資本主義的な取り組みとする必要性もあります。
第2章は方法論に捧げられています。実際、サプライチェーンは競争力のあるシステムです。この組み合わせは単純な方法論を打ち破ります。私たちが紹介した方法論の中で、サプライチェーンのペルソナと実験的最適化は今日のトピックにとって非常に重要です。サプライチェーンのペルソナは正しい意思決定の形式を採用するための鍵です。数分後にこのポイントを再訪します。実験的最適化は実際に機能するものを提供するために不可欠です。同様に、数分後にこのポイントも再訪します。
第3章では、サプライチェーンのペルソナを通じた解決策を一時的に置いて、問題の概要を調査しています。この章では、対処する必要がある意思決定の問題のクラスを特定しようと試みています。この章では、SKUごとに適切な数量を選ぶだけで済むというような単純な視点は、現実世界の状況にはほとんど適合しないことを示しています。意思決定の形式には必ずしも深みがあります。
第4章では、ソフトウェア要素が普及している現代のサプライチェン実践を理解するために必要な要素を調査しています。これらの要素は、数値的なレシピや実際にはほとんどのサプライチェンプロセスが動作する広範なコンテキストを理解するために基本的です。実際、多くのサプライチェンの教科書は、自分たちの技術や数式がある種の真空中で動作すると暗黙的に想定しています。しかし、それは事実ではありません。適用領域は重要です。
第5章と第6章は、予測モデリングと意思決定のためにそれぞれ専用されています。これらの章では、機械学習技術と数理最適化技術を特集した数値的なレシピのスマートな部分をカバーしています。最後に、第7章である現在の章は、数値的なレシピを本番環境に導入し、その後も維持するための定量的なサプライチェンイニシアチブの実行に捧げられています。前の講義では、技術レベルで適切な基盤を築きながら、イニシアチブを開始するために必要な要素について説明しました。つまり、適切なデータパイプラインの設定です。今日は、この数値的なレシピを実行するためにゴールに到達したいと思います。
前の講義では、前回の講義の要点を簡単に復習し、その後、イニシアチブの後半における3つの重要な側面に進みます。最初の側面は、数値的なレシピの設計についてです。ただし、数値的なレシピの数値部分の設計についてではなく、数値的なレシピを取り巻くエンジニアリングプロセス自体の設計について話します。解決策が満足のいくものになる可能性を高めるために、どのようにこの課題に取り組むかを見ていきます。
2番目の側面は、数値的なレシピの適切な展開についてです。実際、会社は手動プロセスから始まり、自動化されたプロセスで終わるべきです。適切な展開は、この移行に関連するリスクを大幅に軽減することができます。少なくとも最初は、数値的なレシピが不具合である可能性に関連するリスクを軽減することができます。
3番目の側面は、自動化が展開された後に会社で起こる必要がある変化についてです。サプライチェーン部門の人々の役割とミッションは、大幅な変化を経る必要があります。
前の講義では、定量的なサプライチェンイニシアチブを開始する方法を見てきました。最も重要な側面を再訪しましょう。成果物は、サプライチェンの意思決定の一部を駆動するソフトウェアである操作的な数値的なレシピです。この数値的なレシピは、本番環境に導入されると、私たちが求めている自動化を提供します。意思決定は、需要予測などの数値的なアーティファクトとは異なるものであり、それ自体が意思決定の計算に貢献することがある中間結果に過ぎません。
イニシアチブの範囲は、システムとその基礎となるアプリケーションの両方と一致している必要があります。サプライチェーンのシステム特性に注意を払うことは、問題を解決するのではなく、問題を解決することが重要です。たとえば、小売チェーンの店舗の在庫最適化が他の店舗に悪影響を与える場合、この最適化は意味をなしません。また、アプリケーションのランドスケープにも注意を払うことが重要です。初期のデータプラミングの努力を最小限に抑える必要があります。ITリソースはほとんど常にボトルネックであり、この制約を悪化させないように注意する必要があります。
最後に、このイニシアチブには4つの役割があります。サプライチェーンのエグゼクティブ、データオフィサー、サプライチェーンサイエンティスト、サプライチェーンプラクティショナーです。サプライチェーンのエグゼクティブは戦略、変化の実施、モデリングの選択肢を調停します。データオフィサーはデータパイプラインの設定を担当し、分析レイヤーで関連するトランザクションデータを利用できるようにします。この講義では、データパイプラインがすでに設定されていると仮定しています。サプライチェーンサイエンティストは、スマートなアルゴリズムの一部だけでなく、多くの計測機器も含まれる数値的なレシピの実装を担当します。最後に、サプライチェーンプラクティショナーは、手動の意思決定プロセスに関与する人物です。通常、この人物はサプライと需要のプランナーの役割を持っていますが、用語は異なります。イニシアチブの開始時には、イニシアチブの終了時までにネットワークマネージャーの役割に移行することが期待されています。このポイントは後で再訪します。
サプライチェーンは、意思決定プロセスの自動化に非常に適しています。数量的な性質を持つ多くの日常的で高度に反復的な意思決定があります。残念ながら、ほとんどのサプライチェーンの教科書で提供されるモデリングの視点は通常、過度に単純化されています。教科書の技術が過度に単純化されているわけではありませんが、それらの教科書で提示される問題の種類は単純化されがちです。たとえば、在庫の補充の状況を考えてみましょう。教科書の視点では、再注文する数量を計算するための最適な在庫ポリシーを求めます。これは問題ありませんが、これはしばしば不完全な回答です。
たとえば、商品を航空輸送するか海上輸送するかを決定する必要がある場合があります。これらの2つの輸送モードは、リードタイムと輸送コストのトレードオフを表しています。複数の適格なサプライヤーの中から1つのサプライヤーを選ぶ必要があるかもしれません。数量が十分に大きい場合は、複数の出荷日を持つ正確な出荷計画を決定する必要があるかもしれません。
このシリーズの第3章であるサプライチェーンの人物についての章では、実際のサプライチェーンの状況の詳細なビューを紹介しました。そこでは、特定のSKUに対して単一の数量を選ぶことを超えた微妙な要素がほとんど常に存在することがわかります。したがって、サプライチェーンサイエンティストは、サプライチェーンプラクティショナーとサプライチェーンエグゼクティブの助けを借りて、意思決定の完全な形式を明らかにする必要があります。意思決定の完全な形式には、実際のサプライチェーンの運用を形成するすべての要素が含まれている必要があります。意思決定の完全な形式を明らかにすることは困難です。
まず、大規模なサプライチェーンを運営するほとんどの企業で実施されている分業は、意思決定のさまざまな側面を複数の従業員、そして場合によっては複数の部門に分散させています。たとえば、再注文する数量を選ぶのは別の人で、どのサプライヤーに発注するかを決定するのは別の人です。
まず、大規模なサプライチェーンを運営するほとんどの企業で実施されている分業は、意思決定のさまざまな側面を複数の従業員、そして場合によっては複数の部門に分散させています。たとえば、再注文する数量を選ぶのは別の人で、どのサプライヤーに発注するかを決定するのは別の人です。
サプライチェーンの意思決定の完全な形態を特定できないこと、またはさらに悪いことに、意思決定を誤って特定することは、イニシアチブを失敗させる最も確実な方法の一つです。特に、レガシーに基づく反応は、大企業でよく起こる間違いの一つです。レガシーに基づく反応の本質は、実際には会社やサプライチェーンにとって意味のない意思決定の形態を採用することですが、既存のトランザクションソフトウェアに適合するか、組織内の既存のプロセスに適合するために採用されます。
たとえば、在庫の補充は、直接実際の再注文数量を計算する代わりに、安全在庫レベルの計算によって制御されることが決定される場合があります。安全在庫の計算は、ERP内にすでに存在するため、比較的容易に感じるかもしれません。したがって、安全在庫の値が再計算される場合、それらの値はDRPで実際に使用された数式を上書きし、ERPに簡単に注入することができます。
しかし、安全在庫には重要な欠点があります。最低注文数量（MOQ）など、基本的な要素でさえ、安全在庫の観点からは適合しません。少なくとも、この実装は、ソフトウェアの一部ではなく、組織内の既存のプロセスによって支持されています。
たとえば、小売ネットワークには2つの計画チームがあります。1つは店舗の補充に専念し、もう1つは配送センターのスタッフレベルに専念しています。しかし、これら2つの問題は基本的に同じです。店舗の再注文数量が選択された後、配送センターに必要なスタッフの量を決定する余地はありません。したがって、2つのチームは基本的に重複するミッションを持っています。この分業は人間が関与している限り機能します。人間は曖昧な要件に対処するのが得意です。しかし、この曖昧さは、再補充やスタッフ要件を自動化しようとする試みにとっては非常に大きな障壁となります。
この反パターン、レガシーに基づく反応は非常に魅力的ですが、実装する変更の量を最小限に抑えます。しかし、意思決定の自動化は、意思決定のアプローチ方法を変えるものです。しばしば、レガシーデザインが維持されると、数量的なサプライチェーンのイニシアチブは失敗するでしょう。
まず、既にかなり複雑な数値レシピの設計をさらに複雑にします。実際、人間の従業員間の分業に適したパターンは、機械的なソフトウェアには適していません。
さらに、レガシーに基づく反応は、自動化に関連する多くの潜在的な利点を無効にします。実際、サプライチェーンでは、会社内に存在する境界に多くの非効率性があります。自動化により、それらの境界のほとんどは不要になります。それらの境界は、もしものために導入されただけであり、もしものために組織の方法を特定の方法で組織する必要はありません。過去2、3十年前に行われた意思決定が、サプライチェーンの将来を決定することはありません。
決定の形式が適切に特徴付けられた後、サプライチェーンの科学者は、歴史的なトランザクションデータを活用して数値レシピ自体を作成し始めます。この講義シリーズでは、学習と最適化に使用できるアルゴリズム技術の詳細について説明します。今日はそれらの要素を再訪することはありません。サプライチェーンの科学者は、自分の知識と経験、およびサプライチェーンの科学者が利用できるツールに基づいて、初期の数値レシピを作成するために一連の判断を下します。
適切なツールと技術を使用すると、この初期の草案は数日、最大でも数週間で実装できるはずです。実際、私たちは新しい技術を発見しようとする高度な研究について話しているのではなく、関心のあるサプライチェーンの特異性を取り入れた既知の技術の適応を作成するだけです。実際、数値レシピは、それらが完全な形で特定された意思決定の細部を厳密に受け入れる必要があります。
非常に有能なサプライチェーンの科学者が最高のツールを活用しているとしても、最初の試みで数値レシピが正しいと期待することは無意味です。実際、サプライチェーンはあまりにも複雑で不明瞭であり、特にデジタル表現においては、数値レシピを最初から正しく作成することはできません。メトリクスやベンチマークのような内向きの数値手法では、サプライチェーンの科学者がデータの誤解を検出することはできません。
会社のトランザクションシステムから得られるすべてのテーブルの各列には、通常、そのデータを解釈するためのいくつかの可能な方法があります。数十の列を数値レシピに統合することを考えると、ミスは避けられません。数値レシピの正確性を評価する唯一の方法は、それをテストし、実世界のフィードバックを得ることです。これは、このシリーズの第2章で「実験的最適化」と題された講義で議論されました。
したがって、サプライチェーンの科学者は、現在の形式の数値レシピに基づいて、数値レシピがまだ正常な結果を返さない状況を特定するために、サプライチェーンの実践者と協力する必要があります。大まかに言えば、サプライチェーンの科学者は、数値レシピによって現在の状況で行われる意思決定を統合するダッシュボードを実装し、サプライチェーンの実践者は正常でないと思われる行を特定しようとします。
このフィードバックに基づいて、科学者は数値レシピをさらに改善します。この計測は、次の質問に答えようとする指標の形で行われます：なぜこのような見かけ上の正常でない意思決定がこの文脈で行われたのか？この計測に基づいて、数値レシピが修正が必要かどうかを決定することができます。たとえば、経済的なドライバーが適切にモデル化されていない場合、または見かけ上の正常でない意思決定が実際には正しい場合、会社のこれまでのやり方とは異なります。
実験的最適化は、非常に反復的なプロセスです。原則として、適切なツールを使用すれば、フルタイムのサプライチェーンの科学者は、数値レシピの新しいイテレーションを毎日提供できるはずです。数値レシピが適切に計測されている場合、イニシアチブが進行するにつれて、実践者は数値レシピの最新のイテレーションについてフィードバックを提供するために1日2時間以上を必要としないはずです。
数値レシピが正常な結果を生成しなくなるまで、つまり、実践者が会社にとって明らかに有害な意思決定を特定できなくなるまで、イテレーションは停止します。正常な意思決定がないことは、手動プロセスと比較して優れた意思決定を生成するという全体的な目標と比較して、低い基準のように思えるかもしれません。ただし、数値レシピは、会社の長期的な経済的利益の数学的最適化を明示的に実行するように最初から設計されています。結果が合理的であれば、最適化は機能しており、さらに重要なことは、最適化基準自体がある程度正しいことを証明しています。
数値レシピの高度なイテレーションプロセスは、初期実装に存在する多くの問題を修正することができますが、最適化に取り組む視点自体が間違っている場合、イテレーションだけでは十分ではありません。この講義シリーズでは、最適化は財務指標に従って行われる必要があると述べてきました。つまり、ユーロやドルで表される指標です。ただし、この声明を明確にします。財務指標を使用しないことは、イニシアチブ全体を危険にさらす間違いです。
残念ながら、大企業は通常、財務指標を避けます。代わりに、ケースによってはゼロパーセントまたは100パーセントに到達した場合に達成されるとされる、ある種の完璧さを表す割合で表される志向的な指標を好みます。自然に、完璧さはこの世界には存在せず、この限界状況は決して到達されません。サービスレベルは、例えば志向的な指標の典型です。100％のサービスレベルは達成不可能であり、非合理な在庫量が必要です。
大企業の一部のマネージャーは、これらの志向的な指標が大好きです。チームは定期的に集まり、これらの指標をさらに改善するために何ができるかを議論します。これらの指標は、会社のコントロール外の要因に依存するため、絶えず見直すことができます。たとえば、サービスレベルは、顧客によって表明される需要の量とサプライヤーが提供するリードタイムに依存します。需要もリードタイムも、会社の完全なコントロール下にありません。
これらの志向的な指標は、人間が意思決定のループに残っている限り、企業の目標として機能します。なぜなら、最初から誰もがサービスレベルを向上させる必要があると合意していても、プランナーは未だに多くの文書化されていない例外を維持するからです。サービスレベルは、在庫リスクが高すぎる場合、最小発注量が高すぎる場合、製品が段階的に廃止される場合、または製品のための予算が残っていない場合など、システム的に増加されます。
残念ながら、これらの志向的な指標は、自動化プロセスを展開する際に有害になります。実際には、これらの指標は不完全であり、会社にとって実際に望ましいものを反映していません。たとえば、100％のサービスレベルを達成することは望ましくありません。なぜなら、会社にとって大量の在庫を作り出すからです。可能な限り、志向的な指標に対してすべての制約、すべての例外を再実装しようとすることは可能です。つまり、数値レシピがプランナーの頭の中で起こっていることを模倣するための多くの制約を志向的な指標に対して設定することを意味します。たとえば、在庫が4ヶ月分以下になる限り、サービスレベルを増やすというルールを定義することができます。ただし、数値レシピの設計と実際の実装のためのこの戦略は、非常にもろいものです。直接的な財務最適化は、はるかに安全で優れた道です。
サプライチェーンの実践者（おそらく複数の実践者）とサプライチェーンの科学者との効果的な協力を実現するために、デュアルラン戦略の早期採用をお勧めします。数値レシピは、既存の手動プロセスと並行して毎日実行されるべきです。デュアルランでは、会社は2つの競合するプロセスを通じて意思決定を2回生成しています。ただし、摩擦があるにもかかわらず、デュアルランには重要な利点があります。まず、サプライチェーンの実践者は、現在の状況に合った新鮮な意思決定が必要です。そうでないと、実践者は自動化された意思決定を理解することができず、狂気じみた部分を特定することもできません。実際、実践者の視点からは、3週間前のサプライチェーンの状況を反映した意思決定は古代史です。過去の在庫レベルを何時間も見直すことにはあまり意味がありません。
それに対して、自動化された意思決定が新鮮で現在の状況を反映している場合、それらの自動化された意思決定は実践者が手動で行う予定の意思決定と競合するものと見なすことができます。当面の間、これらの自動化された意思決定は提案と見なすことができます。
さらに、数値レシピの毎日の実行により、データパイプライン全体が毎日完全な機能テストを受けることが保証されます。実際、数値レシピは正常な結果を返すだけでなく、ITインフラストラクチャの観点からも完璧に動作する必要があります。実際、サプライチェーンは十分に混沌としています。数値レシピはその上に独自の混沌の層を追加してはなりません。数値レシピを可能な限り早期に実稼働条件に置くことは、まれな問題が早期に現れ、データオフィサーとサプライチェーンの科学者がそれらの問題を修正する機会を得ることを保証します。経験則として、数量供給イニシアチブを開始してから3か月目の終わりまでに、数値レシピがまだ本番環境に導入できる準備ができていなくても、デュアルランを実施する必要があります。
また、デュアルランの最初の月の終わりまでに、科学者が適切な仕事をすると、実践者は自動化された意思決定のリストにおいてそれ以外に見逃されていたパターンを観察し始めるはずです。まだいくつかの狂気じみた行があるかもしれませんが、数値レシピのさらなる改善が必要です。
デュアルランが実施されると、サプライチェーンの実践者は、数値レシピによって生成された意思決定を調査するために毎日1〜2時間を費やすことが期待されます。そして、まだ完全に正常でない部分を特定しようとすることが期待されます。しかし、場合によっては、状況が単に不明確になることもあります。意思決定が驚くべきものであるかもしれません-数値レシピが遅いかもしれませんし、そうでないかもしれません。実践者は不確かな状況に感じ、この場合は科学者にいくつかの追加の計測を追加して状況を明らかにするように依頼するべきです。このプロセスは、このシリーズの講義で「数値レシピのホワイトボックス化」と呼ばれているものです。ホワイトボックス化は、数値レシピを株主にできるだけ透明にするプロセスです。ホワイトボックス化は、数値レシピについての信頼を築くためには必要なことです。
自動化された意思決定がダッシュボードのテーブルに集められていると仮定すると、最も一般的な計測の形式は、意思決定の列の隣に追加の列があることです。たとえば、再発注数量を考慮する場合、在庫数量、予想平均リードタイム、予想平均需要など、明らかな計測の列が考慮されることがあります。この計測は、実践者が自動化された意思決定の正常性について迅速な評価を行うために重要です。ただし、数値レシピの上に積み重ねられる計測の量には注意する必要があります。ホワイトボックス化プロセスの一環として自動化された意思決定を飾るために導入される各指標は、意思決定自体に対する視点を少しでも混乱させる可能性があります。良いことが多すぎると悪いことになるかもしれません。データパイプラインが既に安定しているのに、実践者が2か月間の実行後も継続的に追加の計測を要求し続ける場合、問題が発生している可能性があります。
問題の根本原因は、数値レシピのスマートビットに関連付けられる可能性があります。このシリーズの第5章と第6章では、解釈可能性の観点から、すべての技術とモデルが平等に生まれていないことを見てきました。多くのモデルは、データサイエンティストでさえも理解しにくいように設計されています。今日は、解釈可能性の観点から要件を満たすモデルのクラスについて再訪するつもりはありません。この議論のために、数値レシピに埋め込まれたモデルが、サプライチェーンの観点から適切に解釈可能であると仮定します。この文脈では、さらなる計器装置の要求の連続によってイニシアチブが停滞しているように見える場合、最も可能性の高い根本原因は分析麻痺です。サプライチェーンの実践者は、数値レシピに関する評価を過度に厳しく行っています。これが分析麻痺の本質です。実践者は、手動プロセスに対して行われている以上の厳密な審査基準を数値レシピに適用しています。イニシアチブが分析麻痺に陥らないようにするのは、サプライチェーンのエグゼクティブの役割です。そして、それがまだ起こる場合、そして起こるかもしれませんが、サプライチェーンのエグゼクティブの役割は、人間の意思決定も完璧ではないことをチームに優しく思い出させることです。私たちは手動プロセスの改善を求めていますが、完璧ではありません。
数値レシピがもはや狂った決定を生成しないようになり、決定自体が適切な計器装置のレベルを持つようになったら、手動プロセスを自動プロセスに徐々に置き換える時が来ました。一般的な目安として、デュアルランの開始から2〜4ヶ月以内にこのポイントに到達する必要があります。デュアルランの初日から、数値レシピはイニシアチブ全体の範囲で運用されているはずです。したがって、理論的には、手動の意思決定から自動の意思決定への移行は、実際には一晩で行われる可能性があります。
ただし、実践はしばしば理論とは異なります。規模の大きな会社の場合、一晩ですべての意思決定を一つのプロセスから別のプロセスに移行することは重要です。サプライチェーンは非常に複雑であり、予期せぬことが起こることを予想する必要があります。したがって、一つの製品カテゴリのような小さな運用範囲から始めることが賢明です。引き継ぎの初期段階では、各イテレーションに1週間または2週間をかけることが適切です。サプライチェーンの実践者とサプライチェーンの科学者の両方が、自動的な意思決定がどのように実施されるかを注意深く検査する必要があります。そして、この小さな運用範囲で予期せぬことが起こらない場合、この時点で数値レシピがもはや狂った決定を生成しないとしても、自動的な意思決定がトランザクションシステムに統合される方法に問題があるかもしれません。数週間にわたって数値レシピが生産を推進してきた場合、範囲が比較的小さかったとしても、イテレーションを加速することが適切です。
各イテレーションで引き継ぎがより大幅に増加し、イテレーション自体の期間も短縮される可能性があります。実際、自動プロセスへの移行の全体的な時間枠は、合理的に短く保たれるべきです。さもないと、引き継ぎの遅延自体が他のリスクのクラスを導入します。サプライチェーンは変化し続け、その適用領域も変化します。一般的な目安として、企業の規模と複雑さに応じて、引き継ぎは2〜4ヶ月を超えるべきではありません。
サプライチェーンが手動プロセスから自動プロセスに移行するにつれて、組織内での一連の変更が必要になります。大規模な組織は変更が困難であることで知られていますが、変更のための2つの異なる方向があります。組織はプロセスを追加することも、プロセスを削除することもできます。
プロセスを追加することは、人を雇うことを意味し、これに反対するのは会社の最高経営責任者だけです。なぜなら、これは追加の予算項目だからです。プロセスを削除することは、人を解雇するか、少なくとも彼らの仕事を解雇して再教育することを意味します。プロセスを削除する場合、状況は逆転します。組織全体からの反対が予想されますが、最高経営責任者を除いては反対が期待できません。
数値レシピを本番環境に導入する最も簡単な方法は、デュアルランを無期限に維持することです。既存の手動プロセスは保持され、自動的な意思決定を単なる提案として活用します。このアプローチは安全に感じられ、手動プロセスに関連する最悪のミスをいくつか特定することで、わずかな利益をもたらす場合さえあります。ただし、デュアルランを無期限に保持すると、プロセスの堆積が生じ、組織が何かを削除しない状態になります。
サプライチェーンの実践が資本主義的な事業になるためには、組織は手動プロセスを手放さなければなりません。手動プロセスは行き詰まりです。時間とエネルギーを手動プロセスに費やす代わりに、組織は自動化されたプロセスの持続的な改善に全力を注ぐ必要があります。手動プロセスを維持することは、自動化の利点を最大限に活用する能力を妨げるだけでなく、手動介入による再現性のないため、何も真に最適化することはできません。最適化には再現性が必要です。
決定の自動化は、日常的で繰り返しのあるものであっても、サプライチェーンの管理方法においてパラダイムシフトを表しています。この変化は非常に重要であり、完全に無視することが誘惑されるかもしれません。しかし、変化は訪れます。経済の進歩的な機械化が200年続いた結果、一度何かが自動化されると、元の状態に戻ることはありません。Lokadは高度に自動化されたセットアップで約100のサプライチェーンを運営しており、サプライチェーンの自動化は既に存在していることを実証しています。ただし、まだ普及していません。
当社のクライアントが実施する最大の変更の1つは、サプライおよびデマンドプランナーの役割です。この役割の主流形態は、在庫管理者、カテゴリマネージャー、またはサプライマネージャーなど、業界においてさまざまな名前で呼ばれるもので、流量に応じて50から5,000のSKUのリストを所有する従業員が関与します。プランナーは、リスト内のSKUの継続的な入手可能性を確保する責任を持ちます。これは在庫の補充や生産バッチのトリガーを引くことによって行われます。労働分担は簡単です。SKUの数が増えるにつれて、プランナーの数も増えます。
プランナーの焦点は内部にあります。この人は、スプレッドシートにまとめられた数値を確認するために多くの時間を費やします。プランナーは企業向けのソフトウェアツールを活用しているかもしれませんが、ほとんどの場合、自分自身でメンテナンスするスプレッドシートで最終的な意思決定を行います。スプレッドシートの目的は、プランナーの意思決定をサポートするためにアクセス可能で完全にカスタマイズ可能な数値コンテキストを提供することです。プランナーの日常業務は、毎週、おそらく毎日、SKUのリスト全体を見直すことです。
ただし、数値レシピが本番環境にある場合、プランナーによるSKUのリストの定期的なレビュースケジュールを維持する意味はありません。プランナーはネットワークマネージャーの役割に移行すべきです。データ関連のルーチンから大部分が解放されたネットワークマネージャーは、サプライチェーンのネットワークとのコミュニケーション、サプライヤーとの上流、顧客との下流の両方に時間を投資し、数値レシピの設計をサポートする前提条件を見直すことができます。数値レシピに脅威が及ぶのは、精度を失うことではなく、その関連性を失うことです。ネットワークマネージャーは、データのレンズでは見えない要素、少なくともまだ見えない要素を特定しようとします。数値レシピ自体を細かく管理したり、意思決定自体に数値の調整を加えたりすることではありません。数値レシピによって無視されたり誤解されたりしている要素を特定することです。
ネットワークマネージャーは、サプライチェーンの科学者とサプライチェーンの幹部の両方に向けた洞察を統合します。これらの洞察に基づいて、科学者は数値レシピを調整または再構築し、状況の新たな理解を反映させることができます。
残念ながら、数値レシピの導入に反対することは、プランナーが現状を維持するための唯一の方法ではありません。別の戦略は、同じ仕事のルーティンを続けることです。つまり、意思決定を上書きするのではなく、見つかった場合はすべての調査結果をサプライチェーンの科学者に報告するだけです。人々は自分たちの習慣が好きであり、大企業の従業員はなおさらです。
このアプローチの問題は、自動化が導入されると、サプライチェーンの科学者は自動化プロセスの結果を直接観察できることです。プランナーと科学者は同じデータにアクセスできますが、定義上、科学者はプランナーよりも強力な分析ツールにアクセスできます。したがって、自動化が導入されると、プランナーのフィードバックの付加価値は数値レシピの継続的な改善において急速に低下します。
プランナーは分析する時間が増えたため、科学者によって作成されたさまざまな指標とダッシュボードの作成を要求する可能性が高くなります。これにより、「KPIツーリズム」という現象が生じます。レビューする指標の数が増え、それらを単に調査するだけでもフルタイムの仕事になります。この作業量は科学者にとっても邪魔になります。この段階では、展開後、数値レシピの改善には実装の弱点をかなり把握する必要があります。科学者はこの作業を行うために理想的な立場にありますが、プランナーには適していません。プランナーが役立つためには、ネットワークマネージャーになり、先ほど指摘したように外部を見ることが重要です。そうしないと、プランナーの立場はKPIツーリズムに退化します。
サプライチェーンの幹部の仕事は、主に組織とそのプロセスによって定義されます。日常的な意思決定が手動プロセスの結果である限り、各プランナーが独自のSKUのショートリストで作業するという分業は避けられません。したがって、サプライチェーンの幹部はまず第一に、プランナーのチームのマネージャーです。会社が中間管理層を必要とするほど大きい場合、幹部は間接的にプランナーを管理することもあります。それでも、サプライチェーン部門は同じです。プランナーが底辺にいるピラミッド構造です。必然的に、優れたサプライチェーンの幹部であることは、プランナーに対して優れたコーチであることを意味します。幹部はサプライチェーンの意思決定を推進しているのではありません。意思決定を改善することは、主にプランナーによってより良い仕事をしてもらうことです。
サプライチェーンソフトウェアのベンダーは、彼らのツールが違いを生むことを主張しています。しかし、すでに指摘したように、企業内でどれだけのツールが導入されているかに関係なく、ほとんどの場合、スプレッドシートがこれらの意思決定に使用されます。したがって、最終的には、プランナーが自分自身のスプレッドシートで何をしているかにかかっています。
サプライチェーンの意思決定の一部が自動化されると、サプライチェーンの幹部の仕事はかなり変わります。もはや同じ仕事のバリエーションを行っている大勢のプランナーを指導することではありません。仕事は、会社がサプライチェーンの自動化を最大限に活用するために必要なことをするために、サプライチェーンの幹部が行うものです。幹部は、サプライチェーンの意思決定を効果的に推進するソフトウェア製品の所有者にならなければなりません。
実際、サプライチェーンの科学者の焦点と貢献は内向きです。これは、以前のプランナーの貢献と同様です。科学者は内部から数値レシピを改善することしかできません。彼らにはアプリケーションのランドスケープやより広範な会社のプロセスを再構築することは期待できません。これを実現するのはサプライチェーンの幹部の仕事です。特に、幹部は自動化の継続的な改善のためのロードマップを策定する責任を負います。
プランナーによって意思決定が推進されていた限り、ロードマップはほとんど自明でした。プランナーは自分たちがやっていることを続け、次の四半期のミッションは前の四半期とほぼ同じでした。しかし、自動化が導入されると、数値レシピの改善はほとんど常にこれまでに行われたことのないことを行うことを意味します。ソフトウェアを作成する際、正しく行っている場合、同じことを繰り返すのではなく、次に進みます。洞察が得られたら、新しい種類の洞察を求める必要があります。ソフトウェア製品の所有者の下で働く人々のミッションは、設計上、常に変化し続けています。
新しい方向性や目標は空から降ってくるわけではありません。サプライチェーンの幹部の責任は、サプライチェーンのソフトウェア製品の開発を好ましい方向に導くことです。
サプライチェーンが直面する日常的な問題の大部分は、ソフトウェアの問題です。これは、スプレッドシートから手動で派生したすべての意思決定が行われる企業でも、すでに10年以上の間、先進国での事例です。この状況は、サプライチェーンが多くのシステムの交差点にあるためです。ERP、CRM、WMS、OMS、PIMなど、サプライチェーンの目的に関連するデータを含む企業ソフトウェアのさまざまな部分を説明するエンタープライズソフトウェアベンダーが好む3文字の略語が数多く存在します。サプライチェーンはビジネスのエンドツーエンドの視点を求めるため、会社のアプリケーションのほとんどを接続することになります。しかし、多くの企業はまだソフトウェアについてほとんど知識のないサプライチェーンのリーダーを選んでいるようです。さらに悪いことに、それらのリーダーの中には、ソフトウェアについて何も学ぼうとしない人もいます。この状況は、「分析サプライチェーンバス」のアンチパターンです。私がソフトウェアと言うとき、それはこのシリーズの講義の第4章でカバーしたような主題を指すものとして理解されるべきです。それは、コンピューティングハードウェアからソフトウェアエンジニアリングまでのトピックです。
現在、サプライチェーンのトップマネジメントがソフトウェアの素養を持っていないと、会社には大きな問題が生じます。マネジメントがソフトウェアの専門知識なしでうまくやっていけると信じている場合、電子チャネルのすべてで会社は地盤を失います。しかし、多くの従業員が、トップマネジメントが好むかどうかに関係なく、これらの電子チャネルが重要であることを認識しているため、シャドウITは蔓延します。さらに、会社内での次の主要なソフトウェアの移行では、この移行は非常に誤管理され、最初から完全に回避すべきソフトウェア関連の問題による低品質のサービスの長期間が生じます。
マネジメントがサードパーティのソフトウェアの専門知識でうまくやっていけると信じている場合、前のケースよりは少しマシですが、それでもあまり良くありません。専門知識を外部に委託することは、雇用プロセスが規制に準拠していることを確認するなど、狭い自己完結型の問題の場合には問題ありません。しかし、サプライチェーンの課題は自己完結型ではありません。それらは会社全体に広がり、非常に頻繁には会社の外にまで広がります。専門知識を外部に委託できると考えることに関連する最も一般的な落とし穴は、大手ソフトウェアベンダーに過剰な金額を投入し、彼らが問題を解決してくれることを期待することです。驚きですが、彼らは解決しません。これらの問題の唯一の治療法は、トップマネジメントの少しのソフトウェアリテラシーです。
もし管理陣が、サードパーティのソフトウェアの専門知識だけで十分にやっていけると信じているなら、前の場合よりはわずかに良いですが、それほどでもありません。サードパーティの専門家に頼るのは、雇用プロセスが規制に準拠していることを確認するなど、狭い自己完結型の問題がある場合には問題ありません。しかし、サプライチェーンの課題は自己完結型ではありません。それは会社全体に広がり、非常に頻繁には会社の外にまで広がります。専門知識を外部委託できると考えることに関連する最も一般的な落とし穴は、大手ソフトウェアベンダーに過剰な金額を支払い、彼らが問題を解決してくれることを期待することです。驚くことに、彼らは解決してくれません。これらの問題の唯一の治療法は、経営陣が少しのソフトウェアリテラシーを持つことです。
今日は、自動化されたサプライチェーンの意思決定を実現する方法を説明しました。このプロセスは、設計、エンジニアリング、変革の実施の組み合わせです。これは困難な旅であり、数多くの簡単に見える道や安心感のある道が、イニシアチブの失敗に直結することがあります。成功するためには、サプライチェーンのトップマネジメントと従業員の役割と使命の大幅な進化が必要です。
手作業のプロセスに深く根付いている企業にとって、このようなイニシアチブを実施することは困難に思え、そのため現状維持が唯一の選択肢に思えるかもしれません。しかし、私はこの結論には2つの面で異議を唱えます。まず、旅は困難ですが、少なくともほとんどのビジネス投資と比較して安価です。年間の5人分の需要プランナーのコストを再投資することで、企業は50人分の需要プランナーの作業を自動化することができます。もちろん、大企業向けのソフトウェアベンダーは、始めるのに数千万ドルかかると主張することができますが、はるかに効率的な代替手段もあります。第二に、旅は困難かもしれませんが、本質的には選択肢ではありません。日常のサプライチェーンの意思決定を自動化していない企業は、自社の内部プロセスによって引き起こされる長いリードタイムに苦しんでいます。これらの企業は、日常の意思決定プロセスを自動化している企業に対して競争力を維持することはできません。自動化から得られる競争上の優位性は、最初はささやかなものですが、手作業のプロセスは改善できない一方、自動化は時間とともに改善できるため、競争上の優位性は指数関数的に強化されます。現時点では、自動化されたサプライチェーンの意思決定はまだ未来的なものと見なされるかもしれませんが、20年後には逆のことが真実となります。手作業のプロセスは、過去の時代の古くさい名残と見なされるでしょう。
今日の講義はこれで終わりです。すぐに質問に進みます。次の講義は11月の第1週、水曜日の午後3時、パリ時間になります。サプライチェーンのペルソナについての第3章に戻ります。それは架空の会社であるStuttgartという自動車アフターマーケット会社についてです。自動車は産業の中の産業であり、供給チェーンの教科書には適切に反映されていない一連のかなり特殊な課題があります。
質問を見てみましょう。
質問: 数量的なサプライチェーンには、独自の理想的な分業方法が必要ですか？
はい、段階的な移行になるかもしれませんが、アイデアは、手作業のプロセスでの分業がプランナーが管理できるSKUの数によって定義されていたということです。SKUが増えれば、プランナーも増えます。これは非常に単純化された分業です。大企業で自動化プロセスを導入したい場合、アイデアは専門化された人材を持つことです。例えば、ネットワークマネージャーは、クライアントが認識するサービスの品質に特化するかもしれません。認識は重要です。サービスレベルのような抽象的な品質ではなく、クライアント自身の視点です。そのため、その分野に特化したネットワークマネージャーがいるかもしれません。他のネットワークマネージャーは、より緊密な調整と一部のサプライヤーとの統合に特化するかもしれません。例えば、リードタイムを短縮し、新しいオプションを提供することができます。突然、分業は、分析の観点から研究、見直し、再分析する必要がある多くの角度に焦点を当てるようになります。複数の人がそれに取り組むことができます。しかし、再び、それはSKUのリストのように明確に定義されたものではありません。それは何かを改善する本質でもあります。おそらく、人々は一緒にブレインストーミングし、より良いアイデアを特定し、整理するために複数の人が必要なのかもしれません。数量的なサプライチェーンのイニシアチブの道を進むと、分業はより継続的なエンジニアリングプロセスに似たものになり、人々は特定の分野においてより深い知識を持ち、優れた製品を生み出すために協力しようとします。
質問: 財務指標の代わりに割合を使用することは、レガシープロセスの非効率性を隠すのに役立ちます。その場合、イニシアチブが成功する可能性はどのくらいですか？
それは非常に重要な質問です。大企業やその中の多くのマネージャーが、そうした志向性のある指標が好きな理由の1つは、それに責任がないということです。割合として示された指標があると、特定の部門が特定のミスを犯したことによって、過去の四半期だけで数百万ドルが失われたことを誰も気づかないのです。これらの割合は非常に不透明であり、これらのイニシアチブを成功させるのは本当に難しい課題です。なぜなら、ドルやユーロに変換すると、非効率性の真の範囲が明らかになり、それは非常に大きなものになる可能性があるからです。
Lokadの経験では、公開市場にすべての数字を開示し、在庫の価値を証明するために200人以上の監査人が認定している上場企業では、在庫の価値が会社に有利に20%ずれていることがわかりました。その企業の帳簿には100万ユーロ以上の在庫があります。狂気じみたことは、その在庫が数十年にわたって200人以上の人々によって監査され、数十年にわたってデジタル化されていたことです。
こうした問題を明らかにすると、困難ですが、私は問題に対しては厳しく、人に対しては柔軟にアプローチするべきだと信じています。企業は、問題に対しては柔軟に、人に対しては本気で取り組むことを学ばなければなりません。問題を無視して人を解雇するのではなく、問題に厳しく取り組むべきです。
質問: 大企業は必要以上に多くのKPIを使用しています。イニシアチブを展開する際、すべてのKPIにどのように対処しますか？
とても良い質問です。すべてのKPIは、計画者が手動で行っている作業をサポートするための大きな邪魔です。数値的なレシピがあるのなら、なぜすべてのKPIに気を使う必要があるのでしょうか？最適化すべきすべてのことは、財務基準に組み込まれるべきです。潜在的な意思決定ごとに、その意思決定の結果に応じていくらのお金がかかり、いくらの利益または損失があるかを示すメトリックを持つべきです。無限の指標を積み重ねる代わりに、財務メトリックを洗練させたい場合は、要素を追加することができます。ただし、レポートに追加の列を追加するのではなく、与えられた意思決定に割り当てる値にいくらかのユーロまたはドルを加えたり引いたりすることを意味します。
基本的に、これらの財務目標から外れたものは、数値的なレシピによって無視されます。数値的なレシピは、厳密に財務目標を最適化する数学的最適化プロセスを実行しています。これだけです。その他の指標は無視されます。自動化されたセットアップにより、これらの指標が無意味であることが明確になります。これらの指標はレシピに組み込まれず、数値的なレシピによって考慮されず、意思決定プロセスの一部でもありません。また、サービスレベルなどの志向性のある指標は逆効果です。企業にとって望ましい結果ではありませんので、サービス品質を100%にすることはできません。正しく行われると、自動化は指標として実際に必要なものを明確にし、必要な指標はそんなに多くないことに気付かせます。また、プロセスに関与する人数が少ないため、指標を追加し続ける圧力も少なくなります。大規模な計画者チームを持つことのもう一つの側面は、各人が自分自身の1つまたは2つの指標を持つ傾向があることです。200人の人々がおり、各人が個人的な利便性のために1つの指標を追加したがると、200の指標ができあがりますが、これはあまりにも多すぎます。しかし、スタッフの10分の1しかいない場合、指標を積み重ねる圧力はずっと低くなります。
質問: 需要計画ソフトウェアのベンダーは、クライアントへの展開前に、安全在庫の要件など、見込み顧客のエコシステムをどのように理解していますか？つまり、展開が行われると、予測エラーの面で落とし穴はありません。
1970年代に自動化をサプライチェーンの意思決定にもたらすことに失敗したと私は考える古典的な視点は、パッケージ化されたソフトウェアソリューションが企業の問題を解決できるという前提に基づいていました。私は断固としてこれは事実ではないと信じています。パッケージ化されたソフトウェアは、非自明なサプライチェーンには適合しません。在庫最適化と予測モジュールを持つ企業向けソフトウェアベンダーが製品を企業に販売しようとすると、機能が不足しているため、機能を追加し続けます。10年以上にわたって、彼らは数百の画面と数千のパラメータ値を持つ巨大で膨張したソフトウェア製品になります。
ソフトウェア製品が複雑になるほど、会社が持つべきデータに関する期待も具体的になります。ソフトウェア製品が複雑になるほど、クライアント企業に組み込むことが困難になります。既に複雑なサプライチェーンには多くのシステムがあり、超複雑なサプライチェーン最適化製品があります。隙間や不一致があちこちにあります。
実際には、私が話をしたほとんどの大企業は、開発済み国で2〜3十年にわたってデジタルサプライチェーンを運営しており、過去2〜3十年にわたって需要計画、在庫最適化、サプライチェーン設計ソフトウェアソリューションを既に導入しています。ですから、彼らはすでにそこにいて、それを経験してきたのです。これらのプロセスが過去2〜3十年にわたって繰り返し行われていることに、人々は会社に十分な期間在籍していないために気づいていません。それにもかかわらず、プロセスはまだ完全に手動であり、Excelなどのツールに頼っています。問題は予測誤差ではありません。私はそれが問題の誤診であると信じています。なぜなら、あるシステムまたは別のシステムで完璧な予測を行うことができるという考えはばかげています。完璧な予測を生成することはできず、サプライチェーンを手動で操作する人間も完璧な情報にアクセスすることはできません。需要予測を完璧に行うことができるからといって、あなたが人間の需要プランナーであるわけではありません。
需要プランナーは、完璧な予測ではなくとも仕事をすることができます。これらの人々は魔法使いや超高度な科学者ではありません。需要プランナーが予測に関して悪くないかもしれませんが、この業界では、世界中で何十万人もの人々が働いており、非常に正確な需要予測ができると期待する理由はありません。システムが機能するのは、これらの人々が自分たちのヒューリスティックスとサプライチェーンを手動で処理する方法を持っているからです。彼らは手元に予測がなくても、仕事をうまくこなすことができます。
自動化されたセットアップでは、予測が最初からあまり優れていなくても問題なく機能するシステムを持つことが目標です。これが確率的予測アプローチの本質です。精度を高めることではなく、予測があまり優れていないという事実を認識し、受け入れることです。これらのベンダーに戻ると、過去40年間、業界全体が自動化をもたらすことに共同で失敗してきたと私は信じています。問題の核心は、企業がモジュールを接続して終わりにすることを期待されていたパッケージ化の視点でした。これはうまくいきません。サプライチェーンはあまりにも多様で、多目的で、絶えず変化しているため、そのような機械的なアプローチは成功しないのです。
質問: 提示された視点で、企業の販売、在庫などの異なる予測を調整する問題にどのように取り組みますか？
私の質問は、まず予測をする理由はなぜですか？予測は単なる数値の産物です。重要ではありません。企業がより良い予測を行っても、利益が増えるわけではありません。予測は、私がこのシリーズの以前の章で呼んだ通り、数値の産物です。それは、特定のクラスの意思決定に有用であるかもしれない抽象化です。結局のところ、考慮する意思決定によって、必要な予測のタイプは非常に異なる場合があることがわかります。
私は、最初に予測を行い、それに基づいてサプライチェーン全体を組織することができるという考えに異議を唱えます。私はこのアプローチに強く反対しています。なぜなら、私の経験ではそうではなく、それほどうまく機能しないと信じているからです。私は、売り上げ側で予測を行う上級計画プロセスが存在する企業をたくさん見てきましたが、それは大規模なサンドバッグの演習です。営業担当者はしばしば自分の予測を大幅に低く見積もります。なぜなら、もし彼らがそれらの数字を超えるなら、後で期待を容易に超えることができるからです。工場や倉庫の人々はこれらの数字が自分たちに向かって来るのを見て、それが正しくないと思うかもしれません。そのため、数字を破棄してまったく異なることをします。私の意見では、ほとんどの企業が行う予測の演習は、無駄な官僚的な取り組みに過ぎません。それには付加価値はありません。
title: “数量的なサプライチェーンの視点からは、予測ではなく重要な意思決定に焦点を当てることが重要です。予測は技術的な細部に過ぎない場合もあります。一部の意思決定には予測が必要ないか、もしくは現在の企業が考慮している予測とは異なるタイプの予測が必要な場合もあります。予測について話すとき、ほとんどの人は時系列の予測を指します。しかし、この講義シリーズの第3章に戻ってみると、サプライチェーンのパーソナリティと現実世界の状況について説明していることがわかります。時系列の予測はしばしば答えではありません。予測の形式自体がビジネスで特定したいパターンを捉えるのに不適切です。”
“結論として、それらの予測を調整しようとすることはお勧めしません。代わりに、それらを無視し、意思決定に焦点を当ててください。良い意思決定を生成するためのレシピを作成し、おそらくそれらの予測は完全に無視できるでしょう。”
“金融指標とパーセンテージのKPI結果を比較するというコメントに対して、サービスレベルや補充率を財務指標と関連付けて比較することは可能です。しかし、これによって企業の投資対効果が生まれるでしょうか？在庫の意思決定を改善することで企業に価値をもたらすことができますが、KPIの相関関係を調べることはできません。多くの企業はパーセンテージで表されるこれらのKPIに依存していますが、それらはしばしば意味のない煩雑なものです。”
“エンタープライズソフトウェアベンダーは、これらの指標が好きです。なぜなら、それらをクライアント企業に売ることができるからです。その結果、多くのベンダーがさらに多くの指標を求めています。実際には、サプライチェーンの意思決定のクラスでは、1日に見る価値のある10個の数字を持つことは十分です。人間が毎日見る価値のある10個の数字を特定することは通常困難です。それ以下の場合もあり、それは問題ありません。サプライチェーンの問題のクラスは、企業と関連するサプライチェーンに非常に特定的ですが、非常に複雑ではありません。サプライチェーンの状況には数千の経済ドライバーが必要というわけではありません。代わりに、さまざまなサプライチェーンがあり、関心のあるサプライチェーンの微妙なニュアンスに合った正しい問題を解決する必要があります。関心のあるサプライチェーンには、在庫のコスト、粗利益、その他の要素など、コストや財務指標などの3つまたは4つの基本的なドライバーがあるかもしれません。そして、1つのビジネスに特有の4つまたは5つの指標、再び財務指標があるかもしれません。全体として、私たちはまだ10個以下の数字です。”
“財務KPIとサプライチェーンKPIのトレードオフのバランスを取るという質問に対して、イエスとノーと答えます。財務KPIを最適化すべきではないと考えるのであれば、財務KPIの定義自体に問題があります。この講義シリーズの第1章で述べたように、財務指標を確立する際に考慮すべき要素は通常2つのドライバーの範囲があります。第1の範囲には、粗利益、在庫の価値、購買コストなど、財務が直接帳簿で読み取ることができる要素が含まれます。第2の範囲には、顧客の信用とサービスの品質が低い場合の暗黙のペナルティなどのドライバーが含まれます。これらすべてを統合する必要があります。”
“財務の視点は、トレードオフがあるKPIを持つことではありません。代わりに、パフォーマンスと意思決定のためのドルやユーロでのスコアにすべてを統合することです。サプライチェーンのKPIと財務のKPIを調整することではありません。むしろ、企業内にガバナンスを確立することで、在庫の実際のコスト、ストックアウトの実際のコスト、再発注の意思決定が最善の選択肢であるかどうかを合意できるようにすることです。”
“サプライチェーンを駆動するソフトウェア製品を所有するという新しい視点から、サプライチェーンのエグゼクティブの仕事は、企業内での合意形成を促進することです。毎月数値を見直し、意味のない売上高の合意を図ろうとする無意味なS&OPプロセスを推進するのではなく、サプライチェーンディレクターが主導するS&OP 2.0を実施することが重要です。S&OPベンダーが言うようなこととは異なり、CEOはS&OPプロセスを所有する必要はありません。それは彼らにとってはより邪魔なものかもしれません。CEOをすべての戦いに巻き込む必要はありません。”
“サプライチェーンディレクターの使命は、ファイナンス部門長、マーケティング部門長、営業部門長と協力して、サービスの品質などの要因の財務的影響をどのように測定するかに合意することです。これが彼らの仕事です。さまざまなメトリックスの調整は必要ありません。なぜなら、サプライチェーン部門長またはサプライチェーンディレクターの指導のもとで行われた作業により、既に事前に統一されているからです。”
“今日の講義は以上です。次回は11月の第1週にお会いしましょう。”
