00:00:00 導入の章と実践者の枠組み
00:04:35 主流のサプライチェーンの複雑さを打ち破るシンプルさ
00:09:10 無人の意思決定により、ワークフローの迂回を回避
00:13:45 変更管理では、ほとんどの場合、不必要な作業が削除されます
00:18:20 最終的な決定により IT 導入が大幅に短縮される
00:22:55 乱雑な企業データはベンダーの責任です
00:27:30 生き残ったことで、データはすでに十分であることが証明されました
00:32:05 サプライ チェーンの科学者は利益をもたらす決定を自ら行う
00:36:40 一つの心で数値レシピの断片化を防ぐ
00:41:15 説明可能性にはオーナーシップとホワイトボックスが必要
00:45:50 実際に決定事項が表示されると説明が始まります
00:50:25 非常識な決定により、欠落している制約とフィールドが明らかになります
00:55:00 有益な決定は古い習慣を打ち破る可能性があります
00:59:35 導入後は構造ドリフトに対するメンテナンスを意味します
01:04:10 継続的な改善により、時間の経過とともに意思決定の範囲が拡大します
01:08:45 終盤の決断がなければ価値はない
01:13:20 10 週間で本当の進歩が見られるはず
01:17:55 信頼には何か月もかかります。最も難しい問題を最初にテストする
概要
Joannes Vermorel と Conor Doherty は、サプライ チェーンの概要 について章ごとに議論を続けます。第 10 章では展開に移ります。これは、自動化されたサプライ チェーンの意思決定を実稼働環境に導入し、信頼性を高め、プロトタイプのままではなく日常業務を確実に再構築する実践的な作業です。
詳細概要
導入に関するこの議論は、エンタープライズ ソフトウェアにおけるファッショナブルなナンセンスの多くを切り裂きます。中心点は複雑ではありません。サプライ チェーン イニシアチブの目的は、ダッシュボード、ワークフロー、スコアカード、またはその他の装飾的な管理成果物を作成することではありません。その目的は、より良い意思決定を行うことです。いわゆる導入が、無人で監査可能で経済的に健全な決定に至らない場合、その前に行われることの多くは、せいぜい儀式に過ぎません。
業界で繰り返される間違いは、複雑さと洗練さの混同です。多くの企業は、セグメンテーション、オーバーライド、アラート、承認ワークフローのレイヤーを採用しています。これは、これらのことが賢明であるように見えるためです。実際には、より多くのコード、より多くの例外、より多くのあいまいさ、そしてより多くの失敗の機会が作成されることがよくあります。 「より安全」に見えるものは、維持するのが難しくなり、改善が遅くなり、誰もが非難されることは容易になります。対照的に、最終的な決定を生成するために最初から設計されたシステムは、原理的には困難ですが、実際には簡単です。
もう 1 つの重要な点はデータに関するものです。企業は、データが乱雑すぎて自動化をサポートできないと言われることがよくあります。この言い訳は、システムに障害が発生したベンダーにとって役立つため、存続します。しかし、現在も大規模に事業を行っている企業は、サプライチェーンを運営するのに十分なデータをすでに持っています。そうでなければ、とうの昔に倒産していただろう。問題はデータが整然としているかどうかではありません。実際のビジネス システムは決してそうではありません。問題は、ソリューションを構築する人々が、架空のデータセットを要求するのではなく、現実に対処するのに十分な能力があるかどうかです。
したがって、ここで説明されているサプライチェーンサイエンティストの役割は狭いものではありません。それは、単にデータの準備やモデリング、最適化を単独で行うことではありません。これは、生データから最終決定に至るまで、完全な数値レシピの所有権です。その責任を複数の専門家に分割することは効率的であるように聞こえるかもしれませんが、通常は継ぎ目の部分で失敗が生じます。必要なのは、チェーン全体を十分に理解して、それを一貫させて説明できる頭脳です。
説明可能性自体は、ここでは演劇的な方法ではなく実践的な方法で扱われます。抽象化をそれ自体のために説明することはありません。あなたは決定について説明します。そして、その説明は最終的には経済学で還元されなければなりません。なぜこの注文なのか、なぜこの価格なのか、なぜ今なのか、なぜ後ではないのか。利益、損失、リスク、トレードオフの観点から答えを説明できない場合、その説明はおそらく装飾的なものであると考えられます。
より広範な教訓は、導入は野心とスピードによって判断されるべきだということです。簡単なおもちゃの問題ではなく、最も難しい実際の問題を最初に目指してください。何年もかかるあいまいな約束ではなく、数週間で役立つ結果を求めてください。ベンダーが意思決定能力を迅速に発揮できない場合、遅れても無能は解消されません。
全文転写
Conor Doherty: おかえりなさい。これは非常に特別なシリーズのエピソード 10 です。ジョアンズと私は彼の新しい本、サプライ チェーン入門 を取り上げ、そのアイデアについて章ごとに議論します。さて、この特定のシリーズに関して、私は非常に特定の姿勢をとります。ご存知のとおり、私は Lokad で働く人間ではないふりをしています。定量的サプライチェーンについては聞いたことがありません。確かに私はジョアンのことは知りませんし、もう 4 年近く一緒に仕事をしていません。
私は、この本を見て、興味を持ち、読み始め、そして質問をするかもしれない世界中の 1,000 万人ほどの実践者の 1 人のふりをしています。さて、今日は第 10 章です。ということは、もちろん、この前には 9 章がありました。今日私たちが議論した内容は、間違いなく前のエピソードで取り上げられた内容に基づいて構築されているため、最初にそれらを視聴することを強くお勧めします。
それではジョアンさん、それでは始めましょう。第10章、展開。さて、私は今すぐにみんなに約束した姿勢を破るつもりです。そして、ここで働いているコナー、第 4 章は経済学、第 8 章は意思決定について、おそらく私の個人的なお気に入りだと言います。失礼ですが、Lokad を知っている人たちから最も多くのフィードバックを得るのは、おそらく Eight です。
しかし、私がこの本を読んで、最初の数章を読んで「このアプローチがとても気に入っています。意思決定を財務的に定量的にランク付けするというアイデアがとても気に入っています。私は意思決定の半減期について真剣に考えています。私が今何をしているか、それは後で意思決定を開始するのか、それとも終了させるのか？」と純粋に実践者の観点から考えた場合、私もそれには全力で取り組んでいます。彼らは非常に単純な質問をします。「それは一体何のように見えるのですか?」たとえば、上司が私に「それは素晴らしいアイデアですが、それはどうなりますか? 役割は何ですか? 私たちに何が求められますか? データは何ですか? どれくらい時間がかかりますか? 考えられる失敗点は何ですか?」と言ったらどうなるでしょうか?
第 10 章では、実際にそれについて説明します。そこで、その詳細について説明しますが、まず大まかに、デプロイメントが実際に機能するのはなぜであり、デプロイメントが壊滅的に失敗するのはなぜだと思いますか?
Joannes Vermorel: Lokad に関する限り、私たちが成功する企業は、基本的に私たちに取り組みを進めさせてくれる企業です。ばかげているように聞こえるかもしれませんが、基本的にそれは成熟とは何の関係もありません。それで、多くのサプライチェーンディレクターと議論して、「ああ、ある程度の成熟度が必要だ」と言っている人がいますが、ここでは私は同意しません。なぜなら、私たちはどのような成熟度について話しているのでしょうか？
成熟とは、壊れたサプライ チェーン理論に固執することを意味する場合、この道をさらに進めても、Lokad で実際に成功するのには役立ちませんが、サプライ チェーン的に成功するだけです。ご存知のとおり、私がこの本で採用しているスタンスは、つまり、この本はサプライチェーンへの新しい入門書として提示されているということです。したがって、機能しないものすべてについて詳しく説明するわけではありませんが、本質的に実際には機能しないものの長いリストまたはコレクションである主流のサプライチェーン理論とは対照的に、この理論は本質的に機能するものとして読むことができます。
ポイント予測、サービス レベルのマイクロ管理、アラートと例外を通じてサプライ チェーンを管理するアプローチ、すべてをルールベースで行う、すべてを手動で上書きする、などなど、これらすべてがあります。つまり、肝心なのは、Lokad が成功するとき、本質的には、従来のサプライ チェーンが必要とするものよりも、通常は桁違いに単純な何かを試す確かなチャンスを与えてくれる場所であるということです。
問題は、主流のサプライチェーン理論が完全に破綻しているため、実際には悪夢のような複雑さになるということだからです。ご存知のとおり、実際に正しい理論が得られれば、すべてが簡単になります。ソフトウェアはより単純になり、計算はより単純になり、ロジックはより単純になり、ある種の成果物はよりきれいに着地します。これは意思決定と同様、最適化され、リスク調整された意思決定が、イニシアチブの最後によりきれいに着地します。
つまり、教訓が 1 つあるとすれば、それは、誰が実装を担当するとしても、最終的に失敗する理論を追求しないことです。 Lokad では、見込み客やクライアントが本当に効果のあるものを使い続けるように誘導しようとしています。しかし、最終的には直接指示を与えられると、クライアントの意思に反して成功することは非常に困難になります。
Conor Doherty: そうですね、補足のために、明確にするために、すみません、「桁違い」と言うのは単に数値を示しているだけですが、桁違いに単純化すると、展開の観点からは桁違いに単純になるという意味ですか?それとも、成果物という点では、扱いが桁違いに簡単になるということでしょうか?
タイムラインの観点から簡単に説明すると、システムを立ち上げて稼働させるまでに何日かかりますか?どのくらいの工数を投資する必要がありますか?どれくらいの混乱が必要ですか?たとえば、例を挙げてください。
Joannes Vermorel: たとえば、あなたが大好きな ABC 分析のようなもの、または何らかのでっち上げられたセグメンテーションのようなものから始めると、それは必要なかったことがわかります。それは、存在しない問題に対する疑似明白な解決策のようなものです。そこで人々は、「そうそう、サービスの質などを変えることで、セグメンテーションを通じてそれにアプローチする必要がある」と考えます。簡単に言うと、「いいえ」です。このセグメンテーションは必要ありません。
そして、強制的にセグメンテーションを行うと、次のような非常に多くのコード行が存在することになります。カテゴリ A の場合は、これとこれとこれ。カテゴリ B の場合、これとこれとこれ。最近BからAになった製品がある場合、これとこれとこれが必要です。最近 A から B に変わった場合は、何かが必要です。つまり、これは、主流の理論がセグメント化を絶対に受け入れ、好むと思われる単なるアイデアにすぎません。
そして、これはコード的には、エッジケースの迷路にカスケードすることになります。つまり、コード行が増え、バグが増え、最終的にデータ パイプラインから出てくる非常識な決定が増えることになります。したがって、人々が実際に数字を確認するには、より多くの時間が必要です。数字などを理解するにはさらに多くのレポートが必要です。これらのことが次々と重なっていきます。
Lokad が行うことは、確率的予測のように複雑に聞こえるかもしれませんが、そうではありません。文字通り問題のクラス全体を排除し、通常なら数千行のコードが必要な事柄を、わずか数行のコードで表現する方法だからです。それが要点です。シンプルに見えるものではなく、実際にシンプルなものを追求する必要があると思います。これは実際には単純化されているため、大量のルールやエッジケース、そして下流の複雑さにつながっています。
Conor Doherty: それで、これに続けて、あまり多くのアイデアを結合しすぎないように注意したいのですが、もう少し具体的にまとめると、第 10 章であなたが主張していることの 1 つ、これも言い換えていますが、これは非常に忠実であり、展開のコンテキスト、具体的には成果物の観点から、可視性の向上を追求しているわけではないと主張しています。より良いダッシュボードを追求しているわけではありません。より良い予測を追求しているわけではありません。
導入のポイントは、確かにサプライ チェーンの最適化の観点から言えば、無人で監査可能な決定を生成することです。これらの決定には、たとえば、注文書、転送、スケジュール、価格変更などがあり、その後運用システムに書き戻されます。はい。そのほうが簡単です。それがあなたが主張している点です。
Joannes Vermorel: 繰り返しますが、重要なことは放置されています。たとえば、そう決めた場合、「ああ、無人ではハードルがとても高いですね。中間ステップなしで、すぐに良いものに向かって、そのように正しくできるようにしたいのです。」と言うとします。そして、私は「はい」と答えます。なぜなら、代替手段は何でしょうか?
別の方法は、人々が介入してあらゆる種類のオーバーライドを実行できる非常に複雑なワークフローを設計し、最終的にはリソースの割り当て、つまり実際の決定を生成することです。いくらで買えますか？どれくらい生産できますか?在庫はどこに置けばいいですか？価格を上げたり下げたりしますか?したがって、もしあなたが、私たちが無人の決定に真っ向から取り組むと決めたなら、明らかにあなたが言いたいのは、「分かった、私は素晴らしいもの以外の無人の決定は受け入れられない」と言うことです。通常、人間が手動で作成できるものよりもはるかに優れている必要があります。
大丈夫です、問題ありません。それは全く公平な基準です。私が言いたいのは、これが私たちが初日から目標とすべきものであるということです。そして、試してみると、「わかりました。複数ステップのワークフローを使用して、有人でやりたいと思います」などと言うと、サプライ チェーンの最適化であるはずだったプロセスがワークフローの設計に発展し、その後、ご覧のとおり、まったく同じオブジェクトではなくなります。
そして根本的には、時間を費やすのではなく、「サプライ チェーンを通じて割り当てられたすべてのリソースの収益率を本当に最大化するシステムを設計しているか?」これが私たちがプレイしているゲームですが、すべての人の意見を調査し、生産性の最適化を行う必要があるというものに分解されます。ワークフローが「人々に介入してもらう」ため、時間がかかります。
つまり、あらゆる種類のトレードオフが存在します。もっと柔軟性を持たせれば、人々は「ああ、もっと多くのレバーが使えるんだ」と言うかもしれませんが、そうなると従業員がワークフローに多くの時間を費やす可能性があるため、複雑さが生じます。そして、もし終盤の決定が偽りだったとしたら、それは誰の責任なのでしょうか？完全に責任を曖昧にしてしまいます。
特に、ワークフローに 6 人の人が少しずつ工夫を加えていく場合、誰の責任かを指摘することが非常に困難になります。したがって、これらすべての部門に対して因果関係分析を行う必要があります。このようにして、「最大の利益をもたらす決定に真っ直ぐに取り組もう」というところから始めて、完全に脇道にそれて、ワークフローやユーザー インターフェイスの設計、人々の行動の監視、生産性の最適化などに着手しました。
ご存知のように、最初は簡単そうに見えたいくつかのことを実際に実行しただけで、最終的には桁違いに遅く、より複雑なものになる可能性があります。いえいえ、そうではありません。繰り返しになりますが、私たちにとって成功の真の基準は、ワークフローに寄り道せず、セグメンテーションなどの数値的な人工物に寄り道せず、収益性の最大化に真っ直ぐに取り組むことができることです。
結局のところ、ABC には興味がありません。気になるのは、実際に投資収益率を最大化しているかどうかです。クラスを通じて、これを通じて、あれを通じて、またはその他を通じて SKU を細かく分割するかどうかは問題ではありません。つまり、あなたが望むのが、やはり長期的な視点で収益率を最大化することである場合、つまり、短期的な、つまり破壊的な視点を採用せず、長期的な利益を守りながら重要なサービスの質を重視したいと考えており、そのすべてが収益率に反映されます。そうでない場合は、単純な基準を調整する必要があるだけです。
Conor Doherty: はい。そこで特におっしゃったことですが、繰り返しになりますが、カンファレンスであれ、このようなポッドキャストであれ、ビジネス電話であれ、何でもいいので、実践者と話すというアイデアが浮かび上がります。その 1 つは変更管理です。そこであなたが言ったことについて、成功と失敗を分けるものは何かと尋ねると、あなたは、会社があなたに好きなことをやらせてくれる、と答えました。
それに加えて、変更管理では、タイトルに少なくとも何らかの変更があることを意味します。そして、その変化は、セグメンテーション、手動オーバーライド、監視など、先ほど説明したものから離れることになります。自動化、無人の意思決定の方向に進んでいることを受け入れなければなりません。
Joannes Vermorel: そして、繰り返しになりますが、Lokad がもたらす変化が非常に限定的で、ほとんどが減算的なものであることも問題の一部だと思います。ご存知のとおり、それは人々が非常に、時には非常に、非常に混乱することです。 Lokad では、クライアントの企業を再設計する必要はありません。私たちがもたらす変化は、ほとんどすべてが減算的なもの、つまり物事を取り除くものであり、それだけです。
つまり、多くの人の職務内容を再設計して再トレーニングする必要はありません。それは本質的に、私たちが再び無人の意思決定プロセスを目指しているためであり、はい、それらはすべてのレベルで概念的に単純です。 IT にとっては簡単です。サプライチェーンの実務者にとってはより簡単です。経営トップにとってはその方が簡単です。実際、それは誰にとっても簡単です。
つまり、「変化が多すぎて、たくさんのことを学ぶ必要がある」ということではなく、もはや関係のないものをすべて忘れてしまうこととは対照的です。ほら、古いタイプライター、つまり機械式のものと考えてください。油を注ぐ必要がありました。インクリボンを交換できるようにする必要がありました。時々、あなたは取る必要がありました…
若い頃に持っていました。つまり、機械式タイプライターを専門的に使用したい場合、これには多くの小規模なメンテナンスが必要でした。文字通り、ちょっとした時計仕掛けのようなものです。そして、コンピュータにアクセスすると、突然それが消えてしまいます。キーボードは機能します。キーボードが故障した場合は、新しいキーボードを購入するだけで済みます。
最新のキーボードを使用するために必要な知識の量は、昔ながらのタイプライターに比べてはるかに少なくなります。ご存知のとおり、変更管理は非常に減算的です。たくさんのものが消えてしまいました。そして、それはおそらく、私たちが見込み客と話し合っているときに、見込み客にとって最も混乱する部分かもしれません。実際、彼らは、「ああ、人々を再教育する必要がある、あれも追加する必要がある」という意味で多くの変化を期待していますが、その変化はほとんどありません。とても、とても少ないです。
IT にとって、Lokad は、従来のシステムに必要な労力のごく一部に過ぎません。したがって、IT の場合は、はるかに少なくなります。確かにパイロットにとって、それは通常非常に低い摩擦です。基本的には、生のファイル、システムから抽出された行フラット ファイルを送信するだけで、前処理は一切せず、コピー アンド ペーストし、ダンプして転送するだけです。
Conor Doherty: これは重要なポイントです。申し訳ありませんが、これは実際には非常に重要な点であり、先ほど説明しませんでしたが、「準備を整えるだけでも 2 年の導入プロセスが必要である」と比較すると、その効果がどれほど低いかということです。二度とその地点をスピードを出して通過しないでください。
Joannes Vermorel: はい。その理由は、繰り返しになりますが、設計上、Lokad の動作方法は、この意思決定エンジンをワークフローなしで実行することを望んでいるからです。つまり、ワークフローは非常にミニマルです。データが入力され、決定が出力され、それで完了です。
などなど、必要のないものがたくさんあります。ご存知のとおり、ERP と再同期する必要はありません。複雑な処理が山ほどあります。最終的に生成されるのは、ERP に再インポートするのが非常に簡単な最終的な決定だけであるためです。たとえば注文書を生成したい場合、影響を受けるのは製品、数量、サプライヤーだけです。それだけです。注文書が完成したデータ構造は非常にシンプルです。
たとえば、大量のセグメンテーションを管理し、それらを ERP と再同期し、Lokad であらゆる種類の作業を実行してから ERP に再同期できるようにしたい場合とは対照的に、私の同僚のほとんどが提供するのはその類のものです。それが、実装に永遠に時間がかかる理由です。なぜなら、ここでもまた、非常に多くの数値アーチファクトの層が存在するからです。つまり、単なる現実ではないもの、最終製品に到達するための道具のようなもの、つまり決定が必要になるからです。
そして、古典的なサプライ チェーン ソフトウェアでさえ、最終的な決定にさえ至らないことがあります。これは、最小注文数量のチェック、最大コンテナ容量のチェック、トラック積載量のチェックなど、すべての制約を実際に考慮するものです。非常に頻繁に、完全に最終的な決定を目指す代わりに、典型的な高度な計画ソフトウェアである古典的な APS から得られるものは、やはり最終的なものではないという事実から生じる多くの複雑さにも直面することになります。したがって、実際に決定を下すには、後で十分な調整が必要になります。
Conor Doherty: これは、今後も歩み続けるための非常に肥沃な土壌だと私は思います。なぜなら、私たちが IT の関与について話すとき、そしてこれは私たち二人とも、この時点で多くの専門家と話し合ってきたことから再びわかっていることですが、彼らが懸念することの 1 つは、「まあ、私のマスター データは十分ではありません。私のデータの健全性はひどいものです。ジョアン、あなたは私のデータを見るべきです。めちゃくちゃです。下品です。実行不可能です。それを使ってください。」
あなたは第 10 章で、それがまったくの間違いであることをはっきりと理解しています。
Joannes Vermorel: そうそう。そうそう。興味深いのは、繰り返しになりますが、サプライ チェーンのエンタープライズ ソフトウェア ベンダーの市場、つまり、この市場はまったくひどいものであり、ほとんどのベンダーの故障率は 90% をはるかに超えているということです。いや、文字通り狂気の沙汰に聞こえる。大きいです。机上では、数百件の実装が成功しているとされています。実際には、それらはすべてさまざまな程度の失敗です。
そして、データは完璧なスケープゴートであるため、データが失敗するたびに、そしてほとんどの場合、データのせいになります。まさに完璧なスケープゴートですね。天気の神様か何かを責めているようなものです。あたかもデータが宇宙のものであり、私たちはそれとともに生きなければならないかのように、外部の力を非難するだけです。いいえ、いいえ、いいえ。
つまり、私の見解は次のとおりです。たとえば、5,000 万ドル以上の企業では、データはほぼ例外なく優れています。ほぼ常に素晴らしい。なぜ？優れたデータを持っていない企業はとっくの昔に倒産しているからです。それは単なる企業のダーウィニズムです。自分が何を購入しているのかを理解していなければ、サプライヤーに支払う方法が分からず、一部のサプライヤーには二重に支払うか、まったく支払わないことになり、その結果、サプライヤーはサプライヤーでなくなる、またはそのようなことになります。
それで、自分が何を買っているのか分からないのですか？いいえ、自分が何を売っているのか分からないのですか？いいえ。なぜなら、自分が何を販売しているのかを知らなければ、支払いを忘れた顧客などを追いかけることもなくなるからです。したがって、生き残った企業は、基本的に、何を購入し、何を生産し、何を販売しているかを本質的に知っている企業だけです。
Conor Doherty: はい。はい。基本的なルール。
Joannes Vermorel: はい。そして再び、ダーウィニズムが実践されています。それができない企業はずっと昔、おそらく20年ほど前に倒産しました。つまり、生き残った企業は、それらの基本データが正しい企業ということになります。現実を反映しており、使用できるという意味では正しいです。
Conor Doherty: つまり、乱雑さの議論を拒否するということですか？
Joannes Vermorel: いいえ、そうです。つまり、無能なベンダーがこのデータに直面すると何が起こるかということですが、彼らが期待しているのは、ある方法で完全に整理されたデータ、たとえば、Kaggle コンテストが組織されている場合です。適切なテーブルと適切なフィールドを備えた非常に整然としたデータがあり、すべてが非常に適切に文書化されています。しかし、またしても Kaggle のコンテストです。
そうですね、ベンダーとしてそれを期待するとがっかりするでしょう。はい。現実には、そうです、応用的な状況は乱雑です。あなたが直面するのは、6 個の複雑なビジネス システムが存在する環境です。各ビジネス システムには 1,000 ～ 10,000 のテーブルがあり、各テーブルには 10 ～ 500 のフィールドがあります。そして、売上などのあらゆるデータは少なくとも 3 倍になります。したがって、さまざまな理由から、さまざまな表に 3 つの異なる方法で表示されており、それがまさにそのとおりです。
さて、Lokad に関する限り、それを整理するのが私たちの仕事であり、Lokad の責任であると考えています。これは単なる基本的な期待です。したがって、私たちにとっては、何十年にもわたって堆積したものが存在する、非常に乱雑な適用可能な風景以外には何も期待していません。つまり、4 つの異なる ERP があり、そのうちの 1 つは…ERP は実際に停止することはなく、バックグラウンドに移行するだけで、メインフレームや AS/400 などで実行されているものはまだ実行されており、実際にシャットダウンされることはありませんでした。
そして、はい、他のことと同様にそれにも対処しなければなりません、そしてそれはまったく普通のことです。つまり、人々がデータを非難するとき、私にとって実際に非難しているのはベンダーなのです。私にとって、それはほぼ例外なく、ベンダーの無能さの証明です。ベンダーが「そうそう、データが悪かったので失敗しました」と言ったら、とにかく逃げてください。この業者は完全に無能です。自分たちが無能であることも知らずに、天気の神様か何かのせいにしているのです。ただ…データを非難するほうが、「ああ、これに関しては神々が私たちに味方してくれなかった、だから私たちはこの戦いに負けたんだ」と言うよりも、はるかに21世紀的だと感じますが、実際には同じことなのです。
Conor Doherty: これは重要な点であり、実際に詳しく掘り下げていきたいと思います。なぜなら、ここであなたが指摘した 2 つの点を分ける必要があるからです。ただし、重要な点なので繰り返しておきたいと思います。 1 つ目は、「データが乱雑です」というステートメントです。これはここにあります。もう 1 つは、「データが乱雑すぎて、何の熱心な作業もできない」というものです。これらはあなたが主張している 2 つの別々の主張です。
そして実際、あなたの肩の真上に、カメラに映るかどうかわかりませんが、あなたの最初の本、マニフェスト、赤い本があります。そして、あなたが例を挙げている中で、私はそれが90年代のものだと本当に思います、おそらく98ページかそのようなものです、あなたは例を挙げています、発売日は何を意味しますか？そして、6 ～ 10 個ほどの異なる例を挙げています。たとえば、取引データを開くと、それがバスケットに入った日、販売された日、返品期間が終了した日、保証が終了した日などを意味する可能性があります。それが何を意味するかについてはさまざまな解釈があります。それは厄介です。
しかし、あなたが今おっしゃったように、その面倒な作業を手放し、それを使って勤勉で生産的な作業を行うのはベンダーの責任です。
Joannes Vermorel: はい。はい。そして重要なのは、この章の展開に適しているのは、最終的には、手持ちのデータに基づいて、非常に根拠があり、リスク調整された、非常に収益性の高い意思決定を提供する取り組みの成果物を手に入れたいということです。なぜなら、現実には、社内の従業員はこれ以上のデータにアクセスできないからです。
生産マネージャーや在庫マネージャー、購買マネージャーは、発注書や製造オーダーなどを入力する前に、物理的に倉庫に行って詳細情報を取得することはありません。彼らはすべてを自分のデスクから行い、実際にビジネス システム内にある情報を除いて、ほとんどの場合、いかなる種類の特権情報にも特権的にアクセスすることはできません。
つまり、私が主張しているのは、Lokadだということです…なぜなら、あなたの人々、従業員はすでにサプライチェーンを運営できているからです。そうでなければ、再びダーウィニズムが実行され、あなたは破産するでしょう。つまり、あなたが破産していなくても、なんとか事業を継続させている人もいます。これは、データが何らかの形で十分であることを証明しています。あなたの会社がまだ破産していないという事実自体が、データが十分に優れていることを証明しています。
ここで質問です。ベンダーには、希望的観測ではなく、データをそのまま使用するのに十分な能力があるでしょうか?ベンダーが来て、「はい、あなたのデータが私の基準、つまりベンダーの基準を満たしていれば成功します」と言った場合、サプライチェーンを運営する企業であるあなたにはベンダーの基準を制御することはできません。明らかに、これはナンセンスです。
家の配管の修理をしたいと想像してみてください。すると、現れた男性がこう言います。「いや、あのね、私はあなたの配管の配置スタイルがあまり好きではありません。少し複雑に感じます。配管が完全にまっすぐではありません。いいえ、実際に見てもらう前に、あなたの配管が本当に私の基準に達するまで待ってみようと思います。」そして人々はこう言いました。「いいえ、あなたは配管工です。配管の方法に対処してください。そして、完全に真っ直ぐではないパイプがあった場合は、それに対処してください。それが私たちがあなたに期待していることです。」
ほら、この種のデータのせいにするのは非常識です。そして私にとって、このことがこの市場の狂気について多くを物語っているのは、一部のベンダーが、データのせいだという言い訳をして、失敗の原因をクライアントのせいにすることを日常的になんとかやり過ごしているということです。そして最もクレイジーなことは、彼らは非常に頻繁に、それは自分たちのせいだとクライアント自身に納得させようとすることです。
Conor Doherty: そうですね、私にとっては、「おっ」という感じです。ベンダーは失敗しただけでなく、なんとか説得しました…彼らは私にガスライトを当てて、それが私であると思い込ませました。
Joannes Vermorel: わかりました。彼らはクライアントに、それは自分たちのせいだと説得することに成功した。そうですね、それは才能だと思います。これはある意味芸術ですが、操作の専門家ではなくサプライチェーンの専門家であると主張する人々に期待されるものとはまったく異なります。
Conor Doherty: さて、これは実際に次のポイントを設定します。それは、繰り返しになりますが、Lokad がデータを取得する、またはあなたが選択した人が誰を選択すると言った場合でも、私たちの場合は明らかに Lokad であり、私たちはあなたのデータを取得してそれを処理します。実際に意味するのはサプライチェーンの科学者です。そして、それが実際にここでの核心点につながります。それは、導入と継続的改善におけるサプライチェーンサイエンティストの役割です。
しかし、展開段階では確かに、サプライチェーンサイエンティストの役割は、先ほどおっしゃったように、データの解析と整理だけに限定されているのでしょうか、それとももっと包括的なのでしょうか?
Joannes Vermorel: いいえ、最終的な決定を下さなければ、データの処理方法が正しいかどうかは分からないからです。結局のところ、データを使って行っていることが正しいかどうかを知る唯一の基準は、「あなたの意思決定が利益を生むかどうか」ということです。それが…
Conor Doherty: ある意味、データを誤解していても、結果はすべて正しい場合…
Joannes Vermorel: それでは、あなたの誤解は取るに足らないものです。
Conor Doherty: そうですね。
Joannes Vermorel: それで、人々はおそらく驚くでしょう、たとえば、どうして間違いを犯しても問題にならないのですか？繰り返しますが、それは規模のゲームです。何千ものテーブルがあります。合計で数万のフィールドがあります。はい、誤解もあるでしょう。不具合が発生する可能性があります。たくさんのことがあるでしょう。しかし重要なのは、結局のところ、人間も間違いを犯すということです。フィールドを読む人がいるかもしれません。彼らは別のフィールドを読んでいるはずです。
それは実際のところ、あなたは狂気ゼロの意思決定を行っていますか?したがって、直ちに偽となる決定は 1 つもありません。
Conor Doherty: うーん。
Joannes Vermorel: そして、それらはすべて、少なくともそこそこ優れています。そして、経済パフォーマンスを平均して測定したとき、本当に以前の現状を上回っているのでしょうか?それが基準です。
そして、数値レシピを改善し続けて時間をかけて非常に優れたものにするという終わりのない作業ができるという事実は素晴らしいことであり、それはサプライ チェーン科学者の努力の継続です。しかし、最終的には、サプライ チェーン科学者の貢献は次のように解釈されるべきです。「私たちは、これらの非常に収益性の高い意思決定を毎日無人で行うことができるでしょうか?」そしてそれが展開です。これは、毎日決定を下すという点に到達するための取り組みです。
それはサプライチェーンサイエンティストの貢献です。そして、機械的に、または申し訳ありませんが、機械的にではなく、機械論的に言えば、サプライチェーンの科学者は本質的に専門家です。
Conor Doherty: 先ほどの例えだと思います。ピットクルーが全員集合したようなものです。特定のアカウントを管理するのは、エンジニア、データ サイエンティスト、サプライ チェーンの専門家です。たとえば、あなたはその人、あなたのアカウントを運営している人とやり取りしているようなものです。
Joannes Vermorel: そうですね。そして、それはもう少し先に進みます。私が言いたいのは、Lokad にさえ依存していないということです。数値レシピの責任を細分化すると…つまり、誰かが生データを取得して意思決定を生成するソフトウェアを設計する必要があります。私が数値レシピという用語を使用する場合、これは、ビジネス システムに存在するデータから始まり、生のまま存在し、最終的に実際の最終決定を生成するソフトウェアです。
そして、最終的に完了したと言うのは、管理されていない MOQ などがあるからといって、誰もスプレッドシートを開いて数値を調整する必要がないことを意味します。それで、本当に、本当に最終です。良い。発注書は、サプライヤーなどに送信する準備が整いました。わかった。
つまり、私が言いたいのは、サプライチェーンサイエンティストはそのように理解されるべきであり、それはすべてをカバーする 1 つの精神でなければならないということです。人間の心はひとつ。そして、この 1 つの人間の心は非常に重要なものです。なぜなら、最終的には最初から最後まで完全に一貫したものを望んでいるからです。
そして、責任を細分化してみると、それがLokadが 15 年前に学んだことです。このタスクを、「たとえば、データの準備を担当する担当者がいて、次に、たとえば、確率モデリングを担当する担当者がいて、さらに、最終的な意思決定プロセスの最適化を担当する担当者がいる」といったように細分化すると、システム内の境界に大量のバグが発生することになります。
ご存知のとおり、複数の人がいると、この数値レシピ内に自然に境界が設定され、ほぼすべてのバグがその境界に集中することになります。したがって、断片化されないように、これらの境界をすべて削除する方法が必要です。
それを理解するもう 1 つの方法は、チェスのプレイをいくつかの段階に分割するプロセスとして考えることです。たとえば、最初の人が移動の対象となる駒の短いリストを決定し、次に別の人が別のことを決定するなどです。このプロセスを段階的に進めた場合、最終的にはより良いチェスの手を導き出せるでしょうか?いいえ、つまり、チェスのプレイ方法を断片化しようとすると、ほぼ間違いなく、悪いチェス手になってしまいます。もしあなたが本当に上手い人と対戦する場合、その人は、分析を断片化しようとするのではなく盤面全体を見ることができるたった 1 つの頭脳だけで、あなたよりも大幅に有利になるだけです。
Conor Doherty: もちろんです。ある点に下線を引くため、またはその点を明確にし、できれば強調したいのですが、あなたがそれが一人の人間の心であると言うとき、あなたはLokadの側について話していることになります。明らかにクライアントと対話する必要があるため、これは人間の考えによるものです。
Joannes Vermorel: この関係はLokadに関するものではありません。ご存知のとおり、この サプライ チェーンの紹介 は Lokad に関するものではありません。それは、サプライチェーンにおいて何が機能し、何が機能しないのかということです。Lokadについては、別の本の脚注で数回ほとんど言及されていません。
私が言いたいのは、そしてそれが重要な教訓なのですが、サプライチェーンの取り組みを実際に機能させたいのであれば、Lokad が関与しているかどうかさえ問題ではないということです。私が言いたいのは、決定を下すためのソフトウェアが必要だということです。私たちはそれを経験しました。ソフトウェアを持っていない場合、努力や投資は成果を生みません。非常に曖昧になるため、改善することはできません。誰かが退職した場合、繰り返しになりますが、完全に手動で行われているものを体系的に改善するのは非常に困難です。
だからこそ、私は、この数値レシピをソフトウェア成果物としてアプローチする必要がある、と言っているのです。わかった。ここで私が言いたいのは、この数値的成果物の設計と保守に誰かが関与するだろうということです。Lokadが関与している場合、それはLokadの誰かである可能性があります。Lokadが関与していない場合、それは他の誰かになります。どこでも構いません。
そして、私たちが人間と同じくらい自律的で有能なスカイネットレベルの AI を持たない限り、それは人間の心になります。なぜなら、たとえそれらのエージェントが素晴らしいものであったとしても、彼らはまだ単独でそのような複雑な仕事を行うことができないからです。つまり、今のところは人がいるということです。
そして、私が言いたいのは、それが基準であり、会社の規模に関係なく、それは 1 人である必要があるということです。 3人でいることができないという意味ではありませんが、ほら、かなり異なります。考えてみてください。3 人でチェスをプレイしたいと考えている場合、3 人ほどのエキスパートがいる可能性があります。すべての専門家は同等の能力を持っており、全員が自分でゲームをプレイでき、問題全体を把握できます。断片化されていないんです。演出されたものではありません。
つまり、移行を決定するために 3 人程度の専門家がいる場合、ある意味では、その専門家は完全に不要になります。それでいいのです。つまり、私が言いたいのは、心は一つであるべきだということです。実際には、大企業の場合、この人が病気になった場合に代替手段がなくなることを望まないため、冗長性が必要になります。それはわかります。私が言いたいのは、複数の人員がいる場合、基本的に人員削減を導入することになるということです。それは、人々がプロセスの特定の側面について無知であるという問題を細かく切り分ける役割分担のことではありません。
基本的に、それを機能させるには、プロセスを最初から最後まで完全に理解している人が数値レシピを作成する必要があります。それが私が言っていることです。そして、それがなければ、この種の取り組みをほぼ体系的に元に戻す非常に予測可能な問題に遭遇することになります。
Conor Doherty: そうですね、達成しようとしている取り組みそのものを台無しにしてしまう予測可能な問題という点で言えば、最も大きな問題の 1 つは説明可能性です。そして、繰り返しになりますが、私たちは二人とも、「それは素晴らしいですね。無人で自動化された意思決定をエンジニアリングしているこのインテリジェンスシステムと対話しなければならない私のチームに、それをどのように説明すればよいでしょうか? 信頼を築くにはどうすればよいですか? その説明可能性を構築するにはどうすればよいですか? それはどのようなものですか?」という言葉を個人的に聞いてきました。
Joannes Vermorel: それではまず、この「一人、一つの心」に戻ります。わかりますか、説明可能性を担当するのは誰ですか?答えは数値レシピを作成した人です。 AIではありません。それはシステムではありません。それは人です。つまり、自分が何をしたかを説明できる人がいるのです。したがって、この人が説明を受けられない場合、再び問題が発生します。
つまり、私が言いたいのは、成功したデプロイメントに戻るということです。数値レシピの所有権を取得する人が必要です。それが最初のステップです。したがって、説明可能性は、誰かに説明してもらうことから始まります。なるほど、それが役割なんですね。
では、この人は説明ができるのでしょうか？この人が最初から最後まで包括的に理解していれば、たとえ実際にはチームである可能性があるため、作業の一部は他の人によって行われた可能性がありますが、この人が数値レシピ全体を所有している場合は、はい、この人が説明を行うことができます。
さて、あなたが望んでいるのは、この人にインストルメンテーションも作成してほしいということです。これはいわゆるホワイトボックス化の一部です。したがって、数値レシピを作成する人は、すべてのホワイトボックス計測器も作成することになります。それは本質的にあらゆる種類のダッシュボードです…
Conor Doherty: うん、うん、うん。
Joannes Vermorel: …数値レシピを計測します。この計測の背後にある目的は、まず数値レシピを作成する人に、そのレシピが機能していることを確信させることです。つまり、たとえば、注文書を生成する数値レシピを作成します。自分がやったことが正しいと自分に納得させるにはどうすればよいでしょうか?ほら、数式を入れただけです。
Conor Doherty: それは文字通り、私があなたに尋ねている質問です。
Joannes Vermorel: はい。最初の答えは次のとおりです。一連の指標を、はい、ユーロかドルで作成する必要があります。これは、これから何をしようとしているのかを分解して、何が得られているかを教えてくれる…そして、やはり、私が調べたいものにはたくさんのヒューリスティックが存在します。
それで、私は探します…おそらく再び、ホワイトボックス化はちょっとした芸術です。平均だけを見てはいけません。非常に不安定な製品、非常に安定している製品、成長している製品、長期にわたる在庫切れが発生した製品などにズームインしたいと思うかもしれません。つまり、これらはすべて、サプライ チェーンの科学者として、それが実際に意図したとおりに機能していることを自分自身に納得させるために、数値レシピの上に重ねる一種の計測器なのです。
そして、このインストルメンテーションは文字通り何千もの数値であるため、通常は少し圧倒されます。そして、サプライ チェーンの科学者として、説得力のある内容をより簡潔に伝えるために、同僚、クライアント、または他の人々に提示するために、より簡潔なダイジェストを作成したいと考えるのが一般的です。そして、それもまた同じ人物、つまり数値レシピの作成を担当する人物の責任です。
Conor Doherty: そうですね、その回答では、誰が、何を、どのようにして説明しましたか。それで、誰が説明するのか、何を説明するのか、どのように説明するのか。取り上げられていなかったのは、その説明がいつ始まるかです。そして、第 10 章を正しく理解していれば、それはデュアルランフェーズ中です。ここで初めて、新しいインテリジェンス システムが現在のシステムと比較してどのように見えるかがわかります。それでは、拡大してください。
Joannes Vermorel: 問題は、数値レシピには潜在的に何百もの中間計算ステップがあるということですが、数値上の成果物やそれらのものはすべて、目的を達成するための手段にすぎません。重要なのは終わりだけだ、それがあなたがそこにいる目的だからだ。これは、チェスをプレイしている場合に、重要なのは自分の打つ手だけであるのと同じです。この決定を下すために頭の中で考えていたあらゆる種類の中間ステップは、「はい、大丈夫」という感じです。結局のところ、それらは観察者にとっては重要ではありません。本当に重要なのは、実際に何をプレイしているかだけです。それが試合の結果を左右します。
はい。ここで私が言いたいのは、数値レシピについても少し同じことを言っているということです。説明可能性は、説明する決定を下すことで始まると言います。それ以前は、すべてが意味不明だからです。なぜそのような種類の前処理を行ったのか、なぜこのヒューリスティックをあちこちに適用しているのか、なぜリードタイムに別のモデルではなくこの確率モデルを選択しているのかを説明できます。これらはすべて、終わりのない技術的なものです。
基本的に、本当に説明に値するのは終盤、つまりあなたが提案している決定だけです。そして、それが、説明、つまりホワイトボックス化が通常 2 か月目の終わりか 3 か月目の初めにしか始まらない理由です。サプライ チェーンの取り組みにおいて、サプライ チェーンの科学者は実際に毎日の決定を下し始めます。
それまでは、サプライ チェーンの科学者がこれらの決定を下すために行っていることのほとんどが内部的な作業にすぎません。つまり、データ パイプラインを実行し、サプライ チェーンの科学者がこの混乱したデータを処理し、それを理解して、非常に迅速に最初の数値レシピを作成するまでのタイムラインは基本的に 2 か月です。
次の 2 か月間は、すべての非常識な決定を取り除き、実践者からのフィードバックをもとにすべての経済的要因を実際に調整するための迅速な反復です。なぜなら、多くのことは微調整が必要であり、経済的原動力がサプライチェーンや企業の戦略的意図を反映していることを確認したいからです。
では、たとえば、サービスの品質とは実際には何を意味するのでしょうか?繰り返しになりますが、サプライチェーンの科学者は、ここで推測や仮定を置くこともできますが、最終的には、経済的枠組みが本当に企業の長期的な利益を捉えているかを確認するために、実際の実務家との議論が必要になります。そしてそれらは、サービスの質が実際に何を意味するのか、運転資本への圧力などのため、構造がどのように正確であるのかなど、非常に日常的な決定です。
たくさんのことを 2 か月間迅速に反復し、4 か月目の終わりまでに数値レシピを 2 か月間無人で実行してデュアル実行する準備が整います。
Conor Doherty: そうですね。
Joannes Vermorel: 人々が実際に… 数値レシピが必要な信頼を獲得できるようにすることで、人々が実稼働環境でこのソフトウェアに実際に依存してフローを制御することを決定できるようにします。
Conor Doherty: そうですね、あなたは非常識だと言いましたが、あなたが求めているのは狂気のない決断であると以前おっしゃっていましたね。さて、その二重実行フェーズ中、そして、たとえば展開や実装の最初の 6 か月の間に、おそらく、それが Lokad であろうと、誰であろうと、インテリジェンス システムを展開しているときに、このシステムへの信頼を構築しようと観察している人々が決定を観察し、それが欠陥と見分けがつかない、あるいは「ああ、それはただのことだ」と思う瞬間があるでしょう。新しいやり方。」
以前のシステムとこれほど根本的に異なる場合、人々が「それは非常識な決定だ」と言うのか、「いいえ、それは非常識に見えるだけで、実際にはそれが経済的に最善の決定である」と言うのかをどのように区別すると思いますか?
Joannes Vermorel: いいえ、つまり、まず最初に修正する必要があるものは、本当に本当に非常識なものです。わかった？これは、ほとんどの場合、誤解されるフィールドがあることが原因です。繰り返しになりますが、ここでは数千のテーブルについて話しているからです。単位があると思っていても、実際には単位ではなく、キログラムなどであることがあります。あなたは物事を持っています、それは完全にオフです。
そして、非常に頻繁に、たとえば、最初のバッチは、同じ粗利益、同じ株価が見られるかどうかを CFO に確認するだけです。そして、何らかの理由で、最初の試行で最終的に係数 2 の不一致が生じることは珍しいことではありません。つまり、これは狂気の最初の層のようなものです。
そして、シャドー IT もすべて発見します。たとえば、数量を 110 個と提案すると、「いや、いや、違います。教えていませんが、100 単位のパレットでしか提供されません。」と言う人がいます。さて、乗数はたくさんあります。それは文書化されていませんでした。はい。そうですね、それを考慮する必要があります。そして、手を挙げて言う人たちがいます。「ああ、でも、違う、このサプライヤーからは大幅な値下げを受けました。」
Conor Doherty: はい。
Joannes Vermorel: システムには記録されません。通常はスプレッドシートで手動で調整していました。さて、それを修正する必要があります、などなど。つまり、私にとって、反復の最初のラウンドの大部分は、実際には、簡単な狂気と言えるでしょう。それは、データに誤解がある、適切にモデル化されていない制約がある、などです。
また、意思決定を無人で行いたいという目標を自分で設定するため、その目標はより厳しくなります。なぜなら、歴史的に見て、実践者は通常、「ああ、この数字は、そうですね、いいですね、110 です。手動で 100 に四捨五入します。私にとってはこれがいいです。」と言うからです。そして、Lokad はそれをさらに進めて、「いいえ、いいえ、いいえ。多くの乗数が関係している場合、数値レシピはオプションではなく、最後に手動で修正する必要がないようにすべてを行う必要があります。」と言いました。満足のいくものではありません。
つまり、狂気を取り除くということは、こうしたものをすべて取り除くということなのです。そして、はい、その後、歴史的な慣行を反映しない決定が下されることになります。そしてここには経済力が反映されます。そして通常、意見の相違がある場合は、「私たちが見ている金額に同意しますか?」ということになります。 Lokad 氏は、在庫切れのコストと過剰在庫のコストの観点から関係するドルを見ると、これが均衡であると考えています。
そしてここでは、共通の合意を得るために、これらの経済的推進力について反復していきます。そして、それが非常識な決定を修正しなければならない第 2 ラウンドになります。実際、多くの推測に基づく経済的要因が最初は間違っていることが判明するため、企業にとって正しいと思われる基準にそれらを落とし込むために迅速に反復する必要があります。
そして最後に、はい、最後には実務者を驚かせるような決定が下されることもありますが、それが来るのはかなり遅いのです。なぜなら、この時点で私たちが目にしているのは、正常に機能しているシステムで通常起こることですが、古いパターンを打ち破ることだからです。たとえば、特定のサプライヤーへの注文が常に月曜日に行われていたとしますが、これは実際の制約ではありません。
Conor Doherty: そうですね。
Joannes Vermorel: サプライヤーはいつでもご注文を承ります。そして、場合によっては、予想外の需要の急増があったと判断した場合、早ければ早いほど良いという理由だけで、次の月曜日を待たずに木曜日に注文を渡すことが理にかなっている場合もあります。注文を渡す必要があることがすでに分かっているのに、なぜ最初から数日待つ必要があるのでしょうか?それで、いくつかの習慣が崩れることになります。
しかし、ここで再び疑問になるのは、それが収益率の観点から見て正しい行動なのかということです。この動きはより利益をもたらしますか?そして、ここでの変更の実施の範囲は、つまり、古いマニュアルのパターンと一致しない場合でも、これが明らかにより収益性の高いものである場合は、これが決定であるべきであり、それだけであり、それに適合させるために架空の制約を追加しようとする必要はありません。
ところで、これはよく起こったことですが、10 年以上前、Lokad では今よりも経験が浅かったと思います。そして、私たちが抱えていた問題の種類は、見込み客の何人かが、「ああ、私たちはそうしたいのですが…以前のものと比べて、これらの決定は少し変わりすぎます。そこで、ソフトな制約、現実ではない制約を導入しようとしています。」と言うようになることがよくありました。
たとえば、チームはハード MOQ ではなくソフト MOQ を設定するためだけに使用されるため、非現実的な最小注文数量になる場合があります。サプライヤーはそれらを持っていません。倉庫は関係ないよ。それに伴う経済的利益はありません。しかし、購買チームにとって、生産性が非常に低いため、発注書の発行頻度を減らし、時間を節約する方法にすぎませんでした。
しかし、繰り返しになりますが、一度無人意思決定プロセスの領域に入ってしまうと、発注書をバッチ処理することで経済的利益が得られない限り（その場合は数値レシピに反映する必要があります）、完全に作り上げられ何もないところから出てくるソフト MOQ をモデル化しようとしても意味がありません。
Conor Doherty: それを聞いて、ある逸話を思い出しました。それはあなたでした、何年も前、数年前のライブイベント中だったと思います、とあなたは言いました、そしてまた誰がクライアントだったのかは言いません、航空宇宙ではそう言うつもりですが、これは、インテリジェンスシステムを導入して適応を開始すると、信頼を構築する必要があるという考えを示しています。以前は可能だと考えていた範囲を超えた、日和見主義的で一種の資本主義的な決定が生じるでしょう。
その視点から見ると、それは非常識かもしれませんが、実際に経済学を調査してみると、それは理にかなっています。そして、あなたが挙げたと思う例は、「私はそれを解体するつもりですが、非常に簡単に言うと、ある MRO 会社が推奨 PO を持っていて、それにはフルエンジンの購入などが含まれていました。」というものでした。とりあえず、エンジンを買ってみましょう。 A380のエンジンを買う。そして、それは「それは精神的なものです。なぜフルエンジンを購入するように私に言うのですか？」というようなフラグが立てられました。
そしてその正当化は、情報システムが、実際のところ、その地域にあったこれらの飛行機が廃棄されたばかりであることを発見したということでした。このエンジンは現在 50% 割引で販売されています。買ってそのまま座っておけば、6か月以内に売却して利益を得ることができます。つまり、推奨事項は使用するために買うのではなく、売るために買うというものでした。これもまた、「この目的を満たすために必要なものを買う」といった以前の方法とは非常に大きく異なります。一方、これははるかに包括的な経済的観点です。したがって、単に「ああ、この目的を達成するためにこのボックスにチェックを入れていました」というだけではありません。猫の皮を剥いてお金を稼ぐ方法はいくつかあります。
Joannes Vermorel: はい、その通りです。そしてそれは、例えば航空業界などでも今でも起こっています。飛行機は解体されてしまいます。
Conor Doherty: その通りです。
Joannes Vermorel: それで、あなたには購入のチャンスがあります、はい、その一部は…繰り返しになりますが、それはあなたの状況次第ですが、あなたが資金に余裕があり、現金が豊富で、それが何かで、保管スペースが不足していない会社であることがわかっていれば、これはおそらく今から1年後に必要になり、おそらく必要になったときに、現在よりもはるかに高いほぼ保証された価格を支払うことになるでしょう、はい、それがわかるはずです。
あるいは、サプライヤーからプロモーションを受けている小売業者の場合、製品の価値がすぐに失われることはなく、より良い粗利益率で販売する機会が得られます。はい、それはそういうことです…しかし、繰り返しになりますが、だからこそ経済的正当性と説明可能性、説明可能性を基礎づける方法が経済学にあるのです。
そうですね、「なぜそんなことをするのですか？」です。答えは、そうですね、財務を見てください。そして、モデリングがそれが非常に収益性が高く、経済的な観点から合理的であると言うのであれば、たとえそれが会社の歴史的に習慣ではなかったとしても、それは正しい決定です。
Conor Doherty: わかりました。まだカバーしていない唯一のことは、展開後に何が起こるかということです。それで、あなたが会社だとしましょう。あなたはこれをすべて聞いて、それはすばらしいことだと思い、自分自身にインテリジェンス システムを購入したいと考えているとします。導入後は何がベンダーの管理下に残り、何をクライアントとして社内に保持しておくのでしょうか?たとえば、このプロセスのどの部分が完全に私の制御下にあり、何があなたの外部にあるのでしょうか?
Joannes Vermorel: まず、展開に関する大きな教訓は、最終的にどうあるべきかということだと思います。ご存知のとおり、成功したいなら、意思決定を無人で行う必要があります。
Conor Doherty: うーん。
Joannes Vermorel: そうしないと10倍の費用がかかります。それは10倍遅くなり、増加的ではなく、資本主義的でもありません。サプライチェーンに関する限り、会社を収益性の次の段階に本当に引き上げるものは存在しないでしょう。これが本当に簡潔なレッスンです。
そして、ベンダーが関与しているかどうか、社内でやりたいかどうかなどは関係ありません。繰り返しになりますが、この本は実際には Lokad についての本ではありません。これは、「デプロイするとはどういう意味ですか?」ということです。なぜなら、この業界で私が見ているある種のアンチパターンは、多くの人が「ああ、私たちはこのサプライチェーンの取り組みと、これと、これと、これとこれをやった」と言うのに、実際にこの無人の意思決定のような段階に達した人は誰もいないということです。
つまり、無視されるダッシュボードが存在し、無視されるガジェットが存在し、生産性を低下させるだけのソフトウェアが存在することになります。費やさなければならない時間などを考慮すると、文字通り多くをもたらすものではありません。したがって、導入の重要な洞察は、誰が何を担当するかとは関係なく、明確な目標を持つ必要があるということだと思います。信頼できるものにたどり着くことが重要であり、それによって日々の放置された意思決定が生成されます。
そして、私が言いたいのは、これはソフトウェアの一部であり、メンテナンスが必要であるということです。繰り返しますが、ドリフトを避ける人は誰もいません。
Conor Doherty: そうですね。
Joannes Vermorel: スカイネット AI がないからといって、ソフトウェアがどれほど天才的な才能を注ぎ込んだとしても、市場の構造変化に自動的に適応するなどとは期待しないでください。
Conor Doherty: 正直に言うと、これはいつものことです。
Joannes Vermorel: はい、いつもではありません。しかし、ご存知のとおり、構造的ではない変化のクラスがあるからです。市場が上がるか下がるだけであれば、予測モデルや機械学習モデルがそれに対処します。問題は、ビジネスが異なる場合に何が起こるかということです。単に成長しているから、または縮小しているからといって、同じか少なくなるというだけではなく、まったく別の獣になったときに何が起こるかということです。
たとえば、部品を販売していた MRO が、飛行時間に応じた稼働時間を販売するようになったと考えてください。
Conor Doherty: はい。全く異なるビジネスモデルです。
Joannes Vermorel: 同じものを売っているわけでもありません。
Conor Doherty: はい。航空機の部品もあるでしょう。重複するメカニズムが存在します。
Joannes Vermorel: しかし、あなたのビジネスモデルはまったく異なり、インセンティブもまったく異なります。ビジネスの経済モデルはまったく異なります。そして、たとえば、多くの従来型小売業者が電子商取引が主流になった 10 年前にも、同じことが起こりました。したがって、明らかに、従来は実店舗が主流で、現在は電子商取引が主流となっている場合、やはりすべてのインセンティブや戦略など、すべてが変化しています。そして、それは単に売上が増えたり減ったりするだけではありません。それは変革です。あなたのビジネスの本質そのものが変わりつつあります。
繰り返しになりますが、私が言いたいのは、サプライヤーに問題があり、リードタイムが遅くなっているなど、ありふれた変動はすべて、数値レシピを変更せずに処理する必要があるということです。私が言いたいのは、数値レシピだけでは、たとえば新しい ERP を導入するという事実に対応できないということです。
Conor Doherty: はい。あるいは、変更するとか、配送センターを閉鎖するとか、そういったことも含めて。
Joannes Vermorel: はい、その通りです。つまり、非常に構造的なものです。だからこそメンテナンスが必要なのです。それは、このソフトウェアが市場の現実、会社の現実、そしてその適用環境の現実に沿っているかどうかに注意を払い、確実に一致していることを確認してくれる人が必要だからです。
だからこそ、誰が責任者であっても、Lokad ではサプライチェーンサイエンティストと呼んでいますが、数値レシピの作成を担当する人は、その後、数値レシピの保守を担当する必要があります。そして実際には、この担当者に数値レシピの継続的な改善を担当させることもできます。なぜなら、通常、生産に入るときは仕事がまだ始まったばかりだからです。
ある程度の経済的パフォーマンスを達成しましたが、これは通常、手動プロセスだった以前の現状と比較すると大幅な進歩となりますが、これは、最適とみなされるレベルに近づいていることを意味するものではありません。これは単に自分の能力がはるかに向上していることを意味しますが、この資産に投資を続けることで、時間の経過とともに資産を改善することができます。
Conor Doherty: そうですね、また言いたくないです。これは第 10 章には含まれていませんが、これをまとめる価値はあります。これがサプライ チェーン、この場合はサプライ チェーン ソフトウェア、設備投資と運用コストの違いを扱う上での核心だからです。なぜなら、インテリジェンス システムに投資する場合、先ほどおっしゃったように、その意思決定が実際にどれだけ改善され、どれだけパフォーマンスが向上し、どれだけ経済的に見返りが得られるかに上限はありません。つまり、世界には一定のお金しかないのは確かですが、現実的には、それがどれだけ良いものになるかには上限がありません。したがって、それに適切に投資すれば、少なくとも経済的に本当に進むべき方向を向いていることになります。
Joannes Vermorel: はい。はい。そしてまた、それはある程度、起業家的な事業になります。オプションの範囲を拡大するかどうかを決定する必要があります。たとえば、MOQ は当然であると言い始めても、次の段階では MOQ を再交渉する必要があるという決定を下すべきでしょうか?ケースはありますか？サプライヤーとMOQを再交渉することで利益は得られますか?
交渉の内容は何ですか?どのように見えるべきでしょうか? MOQを大幅に下げることができるのであれば、単価を少し高くしても大丈夫でしょうか、それとも逆のことをすべきでしょうか、などなど。サプライ チェーン イニシアチブは、意思決定の点で特定の範囲から始まりますが、時間の経過とともに、より多くの意思決定を行うように拡大する可能性があります。
通常は、フローを支配する基本的な基本的な意思決定から始まりますが、その後、フローを形成する意思決定を重ねることもできます。ただし、通常は最初は当然のこととして考えられますが、これはイニシアチブを根付かせ、最終的には、ますます範囲を拡大する前に、再び無人の意思決定を迅速に提供することになります。
Conor Doherty: そうですね、これが私の最後の考えですが、今あなたが言ったことと同じです。明らかに、最終目標は、会社の財務改善を目的とした自動化された意思決定を無人で行うことです。素晴らしい。これは展開の最終成果物であり、継続的に改善されます。素晴らしいです。
ROI を判断できるか、少なくとも観察できること。つまり、最初の数か月間は、データ検証とデータの並べ替えの段階にあるだけで、実際の経済的価値はまったくないということでしょうか?基本的に、最終製品がなければ、最初のステップには価値がないということですか?それともそのチェーン全体に価値があるのでしょうか？
Joannes Vermorel: いいえ。繰り返しになりますが、ゲーム終盤の決定を下さない限り、自分が正しい道を進んでいるのかどうかは、微塵もわかりません。わかりますか、だから私は、数値的な成果物を追い始めても、分からないと言っているのです。とても良さそうに見えるかもしれませんが、実際には何の手がかりもありません。
繰り返しになりますが、私がチェスについて話していると考えてください。最終的な動きを示唆することなく。もし私が言うとしたら…チェスのゲームがあると想像してください。私はそれがどのようなものか、強い立場、弱い立場などについて何百もの発言をしますが、最後に次にどのような手をとるべきかについては言いません。つまり、このすべてのガイダンスにはどのような価値があるのでしょうか?ほら、それは…
そして問題は、私にとって、多くのエンタープライズ ソフトウェア ベンダーが何十年もの間、この曖昧さを利用して商品を販売してきたということです。彼らはあらゆる種類の数値的アーティファクトを持っているでしょう。 「サプライヤーのスコアカード、製品のスコアカード、これのインジケーター、あれのインジケーター、これとあれとあれとあれをシミュレートするデジタル ツインを提供します」と、果てしないものを提供します。そして、「これは利益を生むのか、それとも損失を生むのか？」という点で合意できる最終決定には何の約束もありません。
そして私が言いたいのは、これは違います…そしてそれは評価の違いです。これは遠い目標ではありません。これも、Lokad の経験では 8 ～ 10 週間以内に到達できるものです。そしてまた、通常は非常に限られたチームで8〜10週間かかります。これは大規模な取り組みではありません。これは…
そして私にとって、それがすべての始まりです。私たちにとって、導入はそうではありません。導入の終了とは、企業が無人の意思決定プロセスを本当に信頼したときであり、これはプロセスの最後の 2 か月のようなものです。そして、多くの企業が気が散ってしまうのは間違いだと私が思うのは、非常に成熟した非常に遠い目標のようなものだと考えている、放置された決定に真っ向から取り組む代わりに、他の目標を追い始めることです。
そして彼らはこう言います。「ああ、10 週間でシステムを完全にロボット化することは不可能です。まずワークフローを確立する必要があると思います。それには 20 週間かかります。」ご覧のとおり、最終段階の 2 倍の大きさと 2 倍複雑な中間ステップを確立します。だからこそ私は、これらの数値的な人工物、主流のサプライチェーン理論から来たアイデアが、最終的には非常に複雑なものを生み出すことになると言っているのです。
こうして、複数年かかるプロジェクトが生まれるのです。そして、何年も経っても、無人プロセスに近いもの、または設備投資に近いもの、生産的な資産があり、投資が増加するものはまだありません。だからこそ私は、これが第一の目標であるかのように議題に載せる必要があると言っているのです。これは私たちがまず始めるべきことであり、その後、それを改善する必要があります。
Conor Doherty: 同意します。そうですね、これに付け加えたいのは、あなたが何度も使った、チェスのたとえ、直喩を実際に使いたいということです。それから、ちょっと言いたいのですが、最後に感想を教えてください。
しかし、展開の最終結果がゲームに勝つためにチェス盤の駒を使って最善の手を打つことであれば、それが最終目標であり、それがインテリジェンスのシステムであり、自動化された決定です。最初の数か月は、データの並べ替えと検証で、スキーマを構築し、解析し、接続を理解し、効果的にチェス盤を構築するか、少なくとも「チェス盤はこれ、マスの色はこれ、駒の見た目はこれ。実際に実行できる動きは次のとおりです。馬の動きはこれです。ルークの動作は次のとおりです。」を示します。
私はまだそこに至っていないので、決定を与えることはできません。しかし、私にとって、「ああ、チェス盤はこんな感じだ。これが駒の役割だ」と知ることには明白な価値がある。
Joannes Vermorel: はい。はい。明らかに。したがって、イニシアチブのリスクを軽減することについて話しているのであれば、はい、進捗状況を感じることができます。うん。しかし、本当のことを言うと、ほとんどのサプライ チェーン ソフトウェア イニシアチブは通常、複数年かけて展開されます。ほとんどのソフトウェア ベンダーは、最低 1 年間の契約を必要とするライセンスを販売しており、多くの場合は 4 年間の契約を必要とします。繰り返しますが、これは完全に偽物です。
私が言いたいのは、もっともっと短いものを撮影すべきだということです。はい。そして、10週間というのはそれほど多くはありません。繰り返しになりますが、このエンティティが、たとえ内部的な解決策であっても、解決に向けて進んでいるのかどうかを知りたい場合は、4 週目に担当者に尋ねるだけで済みます。もう一度、私は 1 つの心で、はい、何をしているのですか?何を作っているのですか？意味が分かりますか？与えられた説明は、「これを使えばたった 6 週間後に完全なレシピが完成するだろうか?」というものでしょうか?
準備のための作業はそれほど多くないと思いますが、エンタープライズ ソフトウェアの壮大な計画の中で、10 週間ほどで最終製品を納品するところまで到達できるというのは、トンネル効果の観点から言えば、それほど大したことではありません。本当に、それほど多くはありません。おそらく、将来的にはコーディング エージェントを使用して、時間を半分に短縮できるでしょう。それでも、それでも非常に高速だと思います。
はい、問題は、ほら、私にはあまり可能性が見えません…この部分を実際に加速するために、これを、たとえば 10 週間のトンネル効果を 5 週間にもたらす可能性はありますが、実際の課題はそこではありません。課題は、現状と比較して、文字通り 100 週間かかる設計のプロセスを目指すのではなく、通常 10 週間で結果が得られるものを目指すことです。
たとえば、導入に関して非常に頻繁に耳にするのは、「ああ、そうだ、いや、そんなことをする余裕はない。10 週間で結果を出す必要がある。RFP を作成することから始める必要がある」、そして、18 か月もかかるということです。さて、あなたは変革を遂げました… 10 週間で結果が得られるものを持っていましたが、今ではベンダーの選択だけで 1 年半かかります。このベンダーの選択には、実際に作業を行うよりもはるかに多くのコストがかかります。
そして、最終的には文字通り、4 年ではなくても 1 年間の契約を希望するベンダーにたどり着きます。さて、これは偽物です。これは、関連するタイムラインのスケールがどのようなものであるかという、デプロイメントの教訓でもあります。
私が言いたいのは、10 週間もあれば無人の意思決定プロセスに到達できるということです。これを完全に信頼するには約 6 か月かかります。そのほとんどは、人間がソフトウェアを信頼するのにかかる時間だからです。テクノロジーとはあまり関係ありません。だからこそ、たとえ明日、機能する数値レシピを実際に実現するのに、たとえば 10 週間かかる遅延をもたらすことができるコーディング エージェントがいるとしても、それは完全に非常識ではありませんが、おそらく明日にはこれを 5 週間、クレイジーなことを言っても 3 週間に圧縮できるでしょう。
実務者や経営陣がこのソフトウェアを信頼し、会社の主要部分を制御できるようになるには、まだ数か月かかります。結局のところ、これは本当の戦いではないと私は言います。本当の戦いは…つまり、ここで数週間を圧迫できるということです。 Lokad はそれに取り組んでいますが、毎日が重要であるため、多くの高度なテクノロジーと非常に洗練された実践が必要です。本当に、本当に速くなりたいと思っています。
しかし、非常に頻繁に、ご存知のように、Lokad、私たちはあちこちで数日を捻出できるようにテクノロジーの開発に取り組んでいます。しかし、私が目にしているのは、私たちが議論している非常に多くの企業です。彼らは、設計上、RFI に行くのに 8 か月、次に 12 か月というようなことをするのに丸々 1 年を費やすことから始まり、その後、8 か月で何かを納品すると言っていた最初のベンダーを選びますが、実際には 1 年半経ってもまだほとんど何も示すものがなく、もちろん自動化されていません。
つまり、ほら、Lokad がこのような非常にイライラする状況を想像してみてください。私たちはある企業と話し合い、その後、企業がプロセスを経て、最終的にパイロットを開始するまでに 5 年かかり、その後 10 週間で完了します。
Conor Doherty: そうですね。
Joannes Vermorel: ご存知のとおり、これは非常に頻繁に起こることです…したがって、これは展開の教訓になるかもしれません。私が言いたいのは、サプライチェーンへの取り組みを展開するには、企業はある意味、はるかに高い野心を抱く必要があるということです。繰り返しますが、無人の意思決定。
小さなことから始めないでください。最も難しい問題から始めたいと考えています。繰り返しますが、なぜですか？内部ソリューションであろうと外部ベンダーであろうと、無能な人材を排除したいからです。問題を解決すると予想される人の実際の能力を評価する方法として、本当に難しいことから始めたいと思うでしょう。
簡単な問題から始めないでください。そうなると、社内のソリューションであれ、外部ベンダーであれ、無能な組織が最終的には無能な仕事をするだけで終わる可能性があります。ただし、フランス語で、小さなデータセットを扱うなど、簡単なものを選択したため、それが行き止まりであることに気づいていません。サプライ チェーンの現代的な道に入ると、最も困難な問題、つまり手持ちの最大のデータ セットを選択し、長期的な解決策になると考えている組織がこの問題について精査され、それが機能することがわかっていることを 10 週間で本当に確認したいと考えます。
このエンティティを簡単なことから精査することから始めた場合、その人またはエンティティがその後難しいことを実行できるかどうかはわかりません。繰り返しになりますが、難しい問題に 3 年ほどかかるとしたら、「いいえ、何か小さなことをする必要がある」と言うでしょう。しかし、私がここで言いたいのは、それも展開の一部ですが、私の知る限り、サプライチェーンには問題はなく、10週間以内に、自分ができるという事実を示すか、無能であるという事実を示す無人の意思決定プロセスを設けることはできないということです。それでおしまい。
そして問題は、ベンダーが 10 週間でそれを実行できなければ、100 週間でもそれを実行できないということです。それでは投資を続けても意味がありません。それがうまくいかなかったことを認めなければなりません。ベンダーを変更し、方法を変更し、より根本的なものを変更する必要があります。ただ時間を与えるだけでは効果はありません。
Conor Doherty: わかりました。ジョアン、これ以上の質問はありません。 1 時間半ほど話してきたと思いますが、非常に実用的な情報を多く取り上げていると思います。繰り返しになりますが、戻って第 10 章を読むことを強くお勧めします。非常に役立つ情報がたくさんあります。しかし、貴重なお時間を割いていただき、そしてご覧いただきまして誠にありがとうございました。
そうです、ご質問がある場合、またはジョアンヌと私に個人的に話したい場合は、LinkedIn でご連絡いただくか、contact@lokad.com までメールをお送りください。あなたはドリルを知っています。それでは、また来週お会いしましょう。仕事に戻りましょう。
