00:22 イントロダクション
02:40 なぜ製品なのか？資本主義のために
08:18 製品は何をすべきか？
10:05 スケールの経済性に関するソフトウェア
12:50 既製のSCO製品を購入しましょう
21:58 SCM vs SCO
25:58 インタールード
28:21 SCOは平均的なソフトウェア製品ではありません
33:26 SCOのためのソフトウェアの要素
42:49 しかし、スプレッドシートは最終目標ではありません
46:51 Pythonも最終目標ではありません
58:52 SCはITの部門ではありません
01:03:19 結論として、克服すべき2つの課題
01:07:04 今後の講義と視聴者の質問
説明
量的サプライチェーンイニシアチブの目標は、ルーチンの意思決定（例：在庫の補充、価格の更新）を自動化するソフトウェアアプリケーションを提供または改善することです。このアプリケーションはエンジニアリングされるべき製品と見なされます。サプライチェーン理論は、生産に関連するすべての制約と互換性を持ちながら、企業をサプライチェーンのパフォーマンスに向かわせるアプリケーションを提供するのに役立ちます。
フルトランスクリプト
皆さん、サプライチェーン講義シリーズにご参加いただき、ありがとうございます。私はジョアネス・ヴェルモレルです。今日は「サプライチェーン最適化のための製品指向デリバリー」を紹介します。
まず、製品と言っているときは、ソフトウェア製品を指しています。現代の企業ソフトウェアの内部を調査したことがある方にとっては、かなりの経験になるかもしれません。
H.P.ラヴクラフトの作品に詳しい方には、いくつかの心配な類似点があります。ラヴクラフトは一連の小説を制作しましたが、その中で頻繁に取り上げられるテーマの1つは、禁断の知識のアイデアです。宇宙が知られることはできるが、宇宙を知ることができるのは人類だけです。ただし、人類を守っているのは無知です。無知は問題ではなく、私たちの心が耐えられないほど恐ろしい宇宙から私たちを守ってくれるものです。このアイデアは、特にロールプレイングゲームなどの現代の多くのゲームに再利用されており、従来の体力ポイントに加えて、キャラクターには正気ポイントがあります。正気を損なう行動をすると、正気ポイントが減少します。企業に価値を追加するためには、正気を保ちながらエンタープライズソフトウェアを作成することが課題です。では、続けましょう。
なぜ製品、特にソフトウェア製品なのでしょうか？伝統的に、供給チェーンはどのように運営されてきたのかを詳しく見てみましょう。伝統的には、多くの人々が物を動かし、パッケージを整理し、車両を運転し、すべての手作業を行っていました。生産には多くの人々が関与し、店舗でも同様でした。ここ数十年間で、青色労働者の数は着実に減少してきています。現在、生産に関しては、事態は大幅に自動化されています。テキスタイルなど、すべてを自動化するのが難しいいくつかの産業は、人件費が最も安い場所に移動しています。実際のところ、人的労力の要件は非常に低下しています。
自律型車両が迫っている将来を見据えると、多くの企業は供給チェーンを運営するためにExcel スプレッドシートを扱うホワイトカラー労働者の数が、現場で手作業を行うブルーカラー労働者の数よりも多くなるという奇妙な状況になります。これが私が事務作業と言及するものです。
もう1つの特異な側面は、多くの企業で供給チェーンが少なくとも20年以上にわたってデジタル化されているということです。供給チェーンにソフトウェアを導入するわけではありません。供給チェーンは既にソフトウェアによって駆動され、運営されています。しかし、これらのソフトウェアシステムにおける人間の役割を見ると、人間は平均的な供給チェーンシステムで人間の共同プロセッサとして使用されています。マシン内の通常のCPU、プロセッサではできない特定の種類の操作があり、その全体のタスクが人間に委任されます。ABC分析、最小最大在庫などの単純な数値レシピと組み合わせて、人間は常に例外や標準的なフレームワークに合わない条件に対処することになります。
コストの観点から、これはすべて運用支出（OpEx）です。企業が日々行うすべての平凡な意思決定を処理するために、毎日大勢の事務員に給与を支払う必要があります。これには何を購入するか、在庫をどこに配置するか、1つの倉庫から店舗に1つのユニットを移動するかなど、多くの日常的な意思決定が含まれます。人間はこれらの意思決定を行い、システムによって単純に生成された自動的な意思決定の不適切さに対処するために消火活動を行っています。
今日の私の提案は、OpExから資本支出（CapEx）に移行したいということです。それがこの製品指向のデリバリーの全体的な目的です。私たちは資産を構築したいのですが、なぜでしょうか？それは資本主義的なのです。現在、世界で最も利益のある100社のうち、半数は利益に関してソフトウェア企業です。彼らは、最小限の限界投資で付加価値を生み出すデバイスやアーティファクトを持つ、超資本主義的な企業の本質を表しています。
前回の講義の話題に戻りますが、管理を再び制御するためにロボット化が必要です。自動化と人間は共に働くべきであり、人間は最小最大などの愚かな在庫ポリシーの不適切さに対処するために存在すべきではありません。代わりに、彼らは価値を追加し、数値レシピを改善し、戦略家として行動するために存在すべきです。かつてIBMのモットーには「機械は働き、人間は考えるべき」という言葉がありました。それがこのプレゼンテーションに込められた考え方です。私たちは、供給チェーンを資本主義的な資産に変えたいのです。そのためには、供給チェーンをソフトウェア製品を提供する機械に変える必要があります。
この製品は実際に何をするのでしょうか？実際には非常にシンプルなことをします。それは意図的で開放的な決定ではなく、どのように生産するか、どのくらいの単位をサプライヤーから購入するか、どのくらいの単位を他の場所に移動するかといった日常的な決定です。初めに見ると、サプライチェーン管理には多くの決定が関与しているように思えるかもしれません。しかし、タスクを調査すると、最も複雑なサプライチェーンでも、毎日数十種類の決定を行うだけで済むことがわかります。これは圧倒的ではなく、機能の数に対して非常に合理的です。興味深いことに、これらの決定はほとんど排他的であり、分割統治のアプローチではできることには限りがあります。サプライヤーから100単位を購入することを決めたら、別のサブシステムが代わりに200単位を購入することはできません。ある時点で、いくつの単位を購入し、他の場所に移動させるかを決めなければなりません。これらの決定は離散的で、範囲が限られており、ほとんど排他的です。私たちが望むのは、毎日完全に自動化された形で注文の決定を生成するソフトウェアです。
ソフトウェアにおける規模の経済の逆説的な概念について、私はしばしば誤解されていると考えています。規模の経済はほとんどの人にとって馴染みがありますが、ソフトウェアでは逆のことが真実です。追加の機能を1/4増やすだけでコストが2倍になることを説明しています。この概念は、小規模なスタートアップが大企業に匹敵することができる理由を説明しています。なぜなら、彼らはより少ない機能に焦点を当てているため、市場に製品を投入するためのコストが大企業よりもかなり少なくなるからです。
規模の経済の逆説的な概念を念頭に置いて、サプライチェーンの最適化製品を構築するか、購入するか、別のアプローチを取るかを決めなければなりません。製品をベンダーから購入する場合、ベンダーが市場に提供するために提供する必要がある機能を考慮する必要があります。
では、棚卸しの最適化製品を既製品で購入することを考えてみましょう。これらのスライドでは、私たちが対処する必要があるもののほんの一部を紹介しています。私は2008年にLokadを立ち上げたとき、予測よりもサプライチェーンの最適化に重点を置いた小さなソフトウェア製品から始めました。クライアントと一緒に仕事を始めると、自分が持っていない機能や機能がたくさんあることに気付きました。他のクライアントに移ると、さらに多くの機能が不足していることがわかりました。新しい要件を発見するプロセスは終わりがないように思われました。
まず、B2CまたはB2Bの企業がありますが、これらはサプライチェーン管理において完全に異なるパターンを示します。たとえば、B2B企業は通常、クライアント数は少ないですが、それらのクライアントははるかに大量の数量を注文します。これにより、企業の売上高の大部分を占める単一のクライアントを失うリスクなど、さまざまな種類のリスクが生じます。また、B2B2CやB2B2Bなどのより複雑なビジネスモデルもあります。
店舗、倉庫、生産施設など、カバーする必要があるさまざまなタイプのサイトを考えてみましょう。各タイプのサイトにはそれぞれ固有の課題があります。たとえば、店舗はRFID技術を使用していても在庫の不正確さが発生しやすいです。なぜなら、顧客が商品を移動させることができるからです。倉庫や生産施設（農場や鉱山など）には、生産量における問題や不確実性があります。
サプライチェーンネットワークには、シングルエシュロンからマルチエシュロンシステムまで、さまざまなレベルやエシュロンが存在します。エシュロンの数が増えるにつれて、サプライチェーンの管理の複雑さも大幅に増します。ネットワークのトポロジーも考慮すべき重要な要素です。ツリートポロジーは、いくつかの生産施設が複数の倉庫に配送し、それらの倉庫が多数の店舗に配布する、古典的なサプライチェーンの経路です。ただし、他のトポロジー、例えば有向非巡回グラフ（DAG）のようなものも存在し、1つの店舗が複数の倉庫から供給されることがあります。
つまり、グラフの観点からはただのツリーではなく、再接続することもできますが、それでも前方のみです。ただし、複数のサプライヤーがある場合、Directed Acyclic Graph（DAG）でも同じことが起こります。修理が必要な場合に発生する修理ループの例として、鉱業業界や航空宇宙業界ではたくさんの修理ループがあります。
さて、在庫自体にはさまざまな性質があります。単に「SKU（Stock Keeping Unit）がある」と言っても、それだけではありません。まず、グラム、キログラム、または体積のような数量で測定される原材料があります。次に、主に一般的なクリーンな単位があります。しかし、薬品業界や食品業界などでは、ロットには特定の賞味期限が付いていることが非常に頻繁に発生します。さらに、完全にシリアル化された在庫も存在し、各ユニットには独自のシリアル番号が付いています。サプライチェーンの最適化の観点からは、これはゲームを完全に変える要素であり、それぞれの要素を見ると、まったく異なる問題になります。
そして、もちろん、マーケットプレイスの問題もあります。Lokadでは、実際にあり得るすべての状況でクライアントを持っています。サードパーティのマーケットプレイスで販売するクライアント、独自のマーケットプレイスを持つクライアント、または両方を持つクライアントがいます。売れ残った商品を処分するために使用する副次的なものである場合もあります。さまざまな状況があります。
例えば、注文というものについて考えてみましょう。スポットオーダーでは、基本的にカウンターで何かを購入し、それがあなたのものになります。しかし、即座に配送されることを望まない注文もあります。「1ヶ月後に配送されるように購入しています」というような注文です。サプライチェーンの最適化の観点からは、これはまったく異なるゲームです。なぜなら、特定の日付に一定数量の商品を配送する必要があることが事前にわかっている場合、それを予測したくないからです。
そして、構成された注文があります。たとえば、オンラインでコンピューターを購入し、メモリの容量、ハードドライブの容量、オペレーティングシステムの種類、コンピューターの設定言語、キーボードの種類などを選択できる場合があります。したがって、大規模な構成ツールがあり、これにより景色が変わります。これは、自転車や車などにも当てはまり、このようなものがあると、サプライチェーンの最適化の問題を見る方法やオプションがまったく異なるものになります。
価格に関しても、単位あたりの価格が一定で単純で直線的な場合がありますが、それだけではありません。たとえば、10個購入すると割引が適用される価格設定があるかもしれません。また、ロイヤリティプログラムでは、ロイヤリティカードを持つ一部の顧客が特定の製品に対して割引を受けることができますが、特定の条件によってのみです。さらに、B2Bでは交渉されることが非常に頻繁なものもあります。これは文字通り多くのものが販売される取引であり、通常のカタログ価格があります。ただし、ベンダーは重要な顧客にリベートを提供する場合があります。要するに、私はたった数分間話しているだけで、まだ核心に触れていません。まだ必要な要素に触れていません。だから、ちょっと立ち止まって、サプライチェーンの最適化を提供するための市販のエンタープライズソフトウェア製品がどのように見えるか考えてみてください。カバーする機能の数は文字通り狂気じみており、それらをすべて一つの巨大なものに組み合わせる方法を考えようとすると、正気を失います。私たちは、宇宙が知り得ないのではなく、宇宙の裸の真実にさらされると、正気を失うという考えに戻っています。
したがって、サプライチェーンマネジメントとサプライチェーン最適化を区別する必要があります。これは以前の講義ですでに紹介した区別です。マネジメントは簿記、ワークフローのサポート、および主にデータ入力プロセスに関するものです。私が説明したすべてのことを表現したい場合、カバーする範囲は非常に広範ですが、可能です。肥満のERPはそれができます。はい、あなたは1万のテーブルを持つことになり、それはかなり醜くなるでしょうが、可能です。ただし、間違いなく、ERP（エンタープライズリソースマネジメントと呼ばれるべき）はあまり多くのことを行いません。それは単にそれらのことを追跡するだけです。したがって、MOQs、チェック；価格設定の割引、チェック；店舗、チェック；倉庫、チェックがたくさんありますが、知能の程度は必要ありません。それは単にデータを反映するための日常的なデジタルの対応物であり、データをシステムに入力することが可能になります。
これは、機能を完全に分離するというルールについて少し妥協することができるためです。機能が互いに干渉しない限り、問題ありません。MOQを駆動するユーザーインターフェースと、ネットワークに追加するためのストアを追加するものが別々になっている必要はありません。これらの2つのことは完全に分離できます。
ただし、サプライチェーン最適化の場合、同じことは当てはまりません。MOQがある場合、発注の頻度、倉庫から店舗への商品の配送頻度に深刻な影響を与えます。遠くまで及ぶ影響がたくさんあります。すべてのものが互いに影響を与えるサプライチェーンでは、それらを分離することはできません。したがって、サプライチェーン最適化の観点からは、最適化を提供するためにこれらすべての要素を接続する必要があり、そこで問題が発生します。
ただし、管理側では製品を最終的に手に入れることができるかもしれません。しかし、サプライチェーン最適化の場合、それはできません。できるように見せかけることはできますが、実際にはできません。Lokadでさえ、最初は予測的なサプライチェーン最適化に特化したサプライ予測会社としてではなく、予測をサービスとして提供することから始まりました。2008年のLokadブログに戻ると、私は最初に時系列の予測を始めましたが、それは非常に誤った方向でした。それでも、それが私のスタートでした。時系列の予測でさえ、それは全体の問題のごく一部に過ぎず、管理できないものです。私はこのビジネスに12年以上携わってきた結果、それが私の結論です。
ソフトウェアの製造の具体的な世界に戻る必要がある場合、それは非常にユニークなものです。ソフトウェアエンジニアとしてのトレーニングを受けており、大規模で成功したソフトウェア会社がソフトウェアをどのように製造しているかに精通している場合を除いては、ほとんど知りません。実際、ソフトウェアの動作については、非常に直感に反する側面がたくさんあります。伝統的な企業、特に古典的な機械工学の考え方やマーケティングの考え方を持つ企業は、ソフトウェアがどのように機能するのかを理解するのに非常に苦労します。
これらの側面については、将来の講義で詳しく説明しますが、私が本当に好きな1冊の本があります。それは、Microsoft Excelの初期チームで働いた元Microsoftの従業員であるJoel Spolskyが制作したものです。彼はまた、Stack OverflowとTrelloの共同創設者でもあります。私がまだ学生だった2004年に、彼の本とブログを読みました。その本のタイトルは「Joel on Software」で、成功するソフトウェアビジネスの運営方法をユーモラスに紹介しています。これは、この業界の外のほとんどの人々が期待するものとは非常に異なります。この本の詳細をビデオの説明に追加します。
ただし、サプライチェーン最適化は平均的なソフトウェア製品ではありません。通常、平均的なソフトウェア製品を扱う場合、いくつかの敵対的な行動があるかもしれません。ソーシャルネットワークを扱う場合、憎悪のあるコンテンツを投稿する人々がたくさんいるかもしれませんが、それはまったく別のゲームです。ただし、Microsoft WordやExcelなどの古典的なエンタープライズソフトウェアを扱う場合、適切な設計を持つことが望ましい製品ですが、緊急事態はありません。伝統的なソフトウェア製品の場合、設計と製品の改善に数年を費やすことは問題ありません。それは長期的な投資であり、数十年先を見越している必要があります。開発に関しては何も急ぐ必要はありません。ただし、サプライチェーン最適化はそうはいきません。常に何かが起こるため、選択肢はありませんし、地形は非常に険しいです。
パンデミックやランサムウェアなどの問題など、極端な状況が発生する可能性があります。ネットワークの半分をシャットダウンする可能性があるようなランサムウェアのような問題が発生する可能性があります。まだ利用可能な能力を最大限に活用するために、スマートな決断をする必要があります。悲劇的な出来事による艦隊の停止、関税のような戦略を破壊する政治的な動き、またはカリフォルニアやオーストラリアのような津波や火災、熱波などの自然災害が発生する可能性があります。これらの出来事は起こりますし、それが起こった場合は、文字通り数時間以内に対応できる必要があります。
ソフトウェア製品はありますが、変更を加える必要があり、プログラムによる変更を加えたいと思うでしょう。覚えておいてください、ソフトウェア資産を提供するという考え方では、一日中消防活動を行っている大勢の事務員を抱えているわけではありません。たとえ大勢の事務員がいたとしても、彼らを訓練する必要があり、完全に予期しない状況が発生した場合、その特定の状況のために訓練されていない軍隊になることになります。私の経験では、管理する人数が多ければ多いほど、何かを達成するのに時間がかかります。
数日前、貨物船が悪天候のために1,800個以上のコンテナを失いました。こうしたことは突然起こるものであり、それらを排除することはできません。サプライチェーンは、すべてが厳密に制御されている生産現場のようなものではありません。定義上、サプライチェーンは広範な世界で起こるものであり、ほとんどの場合、要素に対して制御を行うことはできません。制御できない多くの要素が存在するため、予期しない出来事に対処できるようにする必要があります。予期しない出来事が起こることは既にわかっているので、準備をしておく必要があります。準備とは、すべてを注意深く計画することではなく、必要な場合に数時間で対応できるシステムを持っていることです。それが問題に現実的に取り組むためにできることの本質です。
では、サプライチェーンの最適化に必要なソフトウェアの要素は何でしょうか？まず、多様なデータソースを表現するための柔軟なデータストレージが必要です。表現したいことはたくさんありますので、この点で非常に柔軟なものが必要です。
次に、プログラム可能なロジックが必要です。私はこの考えに戻ります。これらの問題にどのように対処しますか？これらの要素をどのように結びつけますか？すべてがあらかじめプログラムされた製品を購入することはできません。
次に、多様なユーザーインターフェースが必要です。なぜなら、問題をどのように見るかは状況によって大きく異なるからです。KPIは会社によってまったく異なるものになるため、数値を自由に表示できる柔軟なユーザーインターフェースが必要です。そうでなければ、大きな制約になります。
サプライチェーンはチームワークですので、協力能力が必要です。多くの人々が関与しており、分散しているため、協力能力は中心に置かれる必要があります。
最後に、訓練されていないソフトウェアエンジニアでも利用できるプログラム可能な機能が必要です。これはいくつかの理由で重要です。まず、求人市場には訓練されたソフトウェアエンジニアがほとんどいませんので、彼らを雇うことは非常に競争力があります。また、優れたソフトウェアエンジニアになるには多くの努力と献身が必要であり、同時にサプライチェーンの専門家であることは難しいです。
両方の分野に二重の能力を持つ人々を見つけることはあまり一般的ではありません。同じことは、プログラマーであり弁護士でも医者でもある人を探している場合にも当てはまります。はい、これらのスキルセットを持つ人々はいくらかいますが、大企業であれば毎年それ以上の人材をスケールすることができますか？私がLokadを10年間運営してきた経験から言えば、それはうまくいきません。
プログラム可能なものが必要ですが、プログラミングには専門的な訓練を受けたソフトウェアエンジニアである必要はありません。覚えておいてください、サプライチェーンの能力を持った人物が必要です。なぜなら、プログラミングの修正をシステムに適用するために数時間以内に対応できる必要があるからです。チケットを開いてITに渡す必要がある場合、問題を解決するまで数週間かかります。では、実際に問題を解決できるソフトウェアはどのようなものでしょうか？
それはExcelです。見た目は良くないかもしれませんし、現代のソフトウェアの頂点のようには感じられないかもしれませんが、問題を解決することができます。すべての要件を満たしています。
柔軟なデータストレージですか？一部の場合、Excelにはさまざまな種類のデータを格納できます。プログラム可能なロジックですか？もちろん、Excelは完全にプログラム可能です。柔軟なユーザーインターフェースですか？はい、棒グラフ、折れ線グラフ、データを表示するためのさまざまな方法があります。ユーザーインターフェースの面では、非常に柔軟です。最も洗練されているわけではありませんが、柔軟性の面では多くのことができます。
協力的な機能に関しては、少し粗雑です。オンラインで使用できるExcelのバージョンもありますが、基本的にはスプレッドシートを共有できます。協力的な機能の欠如の問題は、デスクトップアプリケーションであることではありません。スプレッドシートに関連するマインドセットが、協力的な作業には適していないためです。通常、非常に複雑なシートを作成した同僚がいる場合、彼らが何をしたのかを理解しようとするよりも、シートを再作成する方が簡単です。したがって、協力的な機能の欠如の問題は、スプレッドシートに付随するマインドセットにあり、協力には強い制限があります。
ただし、Excelは非開発者にも完全にアクセス可能であり、さらに複雑なタスクにはVisual Basic for Applicationsがあります。要素の面では、Excelはすべての要件を満たしています。これが、ほとんどのサプライチェーンでの運用上の成功の大部分を説明していると私は考えています。
私の経験では、世界中のほとんどのサプライチェーンは、最小の企業から最大の企業、エンタープライズソフトウェアに一銭も投資していない企業からサプライチェーンの最適化のために数百万ドルを投資している企業まで、Excelによって駆動されています。ほとんど例外はありません。時には、他のソフトウェアで最小最大設定を修正するためにExcelを使用することもありますが、これらの設定のメンテナンスはExcelで作業している人々に委任されています。
Excelが今日のサプライチェーンの世界を牽引しており、それは偶然ではないと私は信じています。スプレッドシートは、根本的に正しい問題に対処しています。他の多くのオプションは優れているとされていますが、プログラムができない場合はデフォルトで失敗します。プログラムができない場合、重大な問題や緊急事態に直面した場合、運がないです。多目的なユーザーインターフェースがない場合や、非開発者にはアクセスできない場合、人々はExcelスプレッドシートに戻ることになります。結果として、ITチームだけが結果をもたらすことができる場合、最初はチケットを開いて忍耐強く待つかもしれませんが、3ヶ月以内にはほとんどの人がExcelスプレッドシートを使用するようになるでしょう。Excelは最終目標ではありませんが、優れた代替手段を持ち込むにしても、正しい要件を満たす必要があります。
何を改善できるでしょうか？柔軟なデータストレージの面では、Excelは良いですが、非常にスケーラブルではありません。数百万行の処理は問題になります。最新のExcelバージョンでも100万行を処理できますが、スケールでの操作ではすぐにパフォーマンスの問題が発生します。Excelでプログラム可能なロジックは可能ですが、非常に壊れやすくてもろいです。スプレッドシートに誤りやバグを誤って導入すると、問題のデバッグや原因の特定が困難になります。ロジックは無限に複製され、同じロジックのコピーが数千個作成されるため、エラーの特定と修正が困難になります。
ユーザーインターフェースは理想的ではありません。完全にWebベースではなく、データは常にインターフェースと絡み合っています。共同作業の機能は存在しますが、乱雑です。共同作業はプログラム可能なロジックのレベルで行う必要があります。多くのサプライチェーン最適化ベンダーは、予測を手動で微調整したり、複数の人が参加できるようにしたりすることで、出力に対する共同作業を提供しています。しかし、これは間違ったアプローチです。共同作業は必要ですが、プログラム可能なロジックのレベルで行う必要があります。Excelは非開発者に非常にアクセスしやすいですが、やや複雑なことをする場合は難しくなります。サプライチェーン管理では、確率的予測、ランダム変数、不確実性に対応する必要があります。これはExcelで可能ですが、かなり複雑です。Excelは簡単なタスクには適していますが、より複雑な状況ではExcelのウィザードになる必要があります。
メンテナンス性は重要です。時間の経過とともに価値が成長する資産を構築したいと考えています。スプレッドシートでは、これを実現するのは難しく、少なくともソフトウェア製品の意味で真に正確なものを作成するのは困難です。
現在のキーワードはAIとPythonであり、データサイエンスを取り巻くトレンドとハイプがあります。ただし、サプライチェーン管理においては、PythonはExcelに劣っていると考えています。
誤解しないでください。私はPythonが好きで、素晴らしい言語だと思っています。私は10歳の娘にも教えています。ただし、サプライチェーン管理においてPythonが最適な選択肢ではない理由がいくつかあります。まず、ソフトウェアエンジニアが必要です。Pythonは最もアクセスしやすいプログラミング言語の1つですが、より複雑なことをする場合は、サプライチェーンの専門家でありソフトウェアエンジニアでもある人材が必要になります。
Pythonには素晴らしい機能がありますが、依存関係の扱い方は非常に複雑で、パッケージ管理が貧弱です。パッケージは追加の機能を提供するビルディングブロックであり、Pythonを使用するときに興味があるのは言語だけでなく、NumPy、Pandas、TensorFlow、SciPyなどのサードパーティの依存関係やソフトウェアライブラリなど、エコシステム全体です。パッケージ管理は10年以上にわたって不十分であり、改善は進んでいますが、進捗は遅いです。システムの設計には多くの難点があり、拡張が困難になっています。
パフォーマンスも設計上の理由で低いです。計算パフォーマンスは、Pythonがコンピュータの利用可能な計算能力を最大限に活用するための品質を指します。驚くべきことに、Microsoft Excelはこの点ではるかに優れた仕事をします。Excelは高度に最適化されており、マルチCPU、マルチコアシステムを活用し、ネイティブコンパイルされたロジックを実行します。MicrosoftはExcelを非常に高速化するために多くの投資を行っています。
対照的に、Pythonには固有の問題があり、パフォーマンスが理論上のマシンの提供能力の100倍遅くなることがよくあります。現代のコンピュータのパワーを考えると、それでも一部の人には受け入れられるかもしれませんが、取引量が5000万ドルを超える企業にとっては理想的ではありません。最初から良いパフォーマンスを提供するものが必要です。
Pythonのパフォーマンスの問題を解決するためにNumPyのようなサードパーティライブラリを使用すると、複雑さが増します。パフォーマンスの問題は解決できるかもしれませんが、NumPyの追加の複雑さを導入することで新たな問題が生じます。これにより、ソフトウェアエンジニアリングの問題のハードルも上がります。
Pythonの実際のサプライチェーン管理のためにPythonのソリューションを実装しようとすると、null参照例外、メモリ不足例外、長時間の計算時間など、さまざまな問題が発生します。計算が完了するまで20分待つことになり、それが完了するかどうか、またはプロセスを終了して再起動するかどうかわからない状況になるかもしれません。私はわかりませんので、完了までにかかる時間の非常に良いアイデアがあるものが欲しいです。ちなみに、Excelに戻ると、現在、少し時間がかかる操作がある場合、Excelはかなり信頼性のある進行状況バーを表示してくれます。ですから、生産準備の一環として、求めているものは、データサイエンティストが全体を見守る必要がないものです。
そして、もしデータサイエンティストの問題がある場合は、第三の能力が必要です：サプライチェーンの専門家、ソフトウェアエンジニアリングの専門家、そしてデータサイエンティストの専門家です。これらの3つの資質を1人で持つことは可能ですが、それらのスキルを持つ大企業であっても、1年に1人以上の人材を採用するのは非常に困難です。
ですから、改善されるものが欲しいです。ちなみに、最初に改善したいのは、深層防御です。ランサムウェアは増加しており、組織にプログラム可能なものを導入すると、ランサムウェアの攻撃にさらされることになります。なぜなら、突然、プログラムがあると、そのマシン上で実行されているプログラムは、ハイジャックを含むさまざまなことができるからです。問題を緩和するためのたくさんの方法があることはわかっています。サンドボックス化することもできますし、制限することもできますし、権限を制限することもできます。問題を制限するためのたくさんの方法があります。それにもかかわらず、一般的な汎用プログラミング言語のようなものを持っている場合、攻撃面積は絶対に巨大です。
つまり、そのようなコードを接続するたびに、セキュリティの問題に対して大きなリスクを負うことになります。そして、通常のソフトウェアエンジニアリングビジネスでは、コードはピアレビューされます。コードをレビューし、コードレビュープロセスがあります。誰かがコードを作成し、同僚がコードをレビューして、コードに問題がないことを確認します。しかし、ソフトウェアが頑丈である必要があるという事実に戻ると、数時間以内に対応する必要があります。サプライチェーンの最適化の観点からは、コードレビュープロセスを導入することはできません。それは遅延や緊急事態とは両立しないからです。
ですから、デザインによる深層防御を備えたものが必要です。そして、透明なパフォーマンスを持つものが欲しいです。はい、時間がかかることもありますが、それを制御する必要があります。事前にどれくらいの時間がかかるかを知る必要があります。それがない場合、納期が2時間のウィンドウがあり、遅れてしまったという非常に愚かな問題に直面することになります。そして、ご存知のように、トラックはすでに出発しています。遅すぎます。ですから、それが対応されるようなものが必要です。
また、透明なアップグレードにも同じことが言えます。それがExcelの美しさです。Excelのメンテナンスについて考える必要はありません。マイクロソフトは数十年前に血の契約を結びました。それは、Excelスプレッドシートを作成した場合、市場に登場する次のバージョンのExcelは、あなたのスプレッドシートをサポートできるというものでした。そして最も信じられないことは、Excelを見ると、現在では存在しない競合他社のExcel形式をサポートしていることです。Lotus Notesで作成されたスプレッドシートなどもまだ読むことができます。マイクロソフトの透明なアップグレードの価値提案は、あなたが作成したロジックが永遠に機能するということです。そして、数十年にわたってExcelを改善し続けるでしょうが、それは対応されています。それは、Python 2からPython 3への移行を見るときに見られるものではありません。それは悪夢であり、10年かかりました。ですから、Pythonは多くのことに適していますが、最悪の瞬間にアップグレードが行われることを想像してみてください。最悪のパンデミック、最悪の関税、最悪の緊急事態が発生し、物事が稼働して準備が整っている必要があります。アップグレードのために6ヶ月間のダウンタイムが必要なわけではありません。それは供給チェーンの最適化とは相容れないものです。
では、供給チェーンを考慮したエンジニアリングが実際に行われる場合を考えてみましょう。それが次の講義のトピックです。
また、サプライチェーンはITの分野ではありません。私が製品指向のデリバリーと言うとき、ソフトウェアは単なる手段であり、目的ではありません。あなたはソフトウェアをライセンス料や料金で販売することはありません。私がこの講義であなたの前に描いているビジョンでは、ITはコアのプラクティスに責任を持ちます。セキュリティ、バックアップ、コアインフラストラクチャ、ネットワーク、会社レベルでのデータの管理と同期など、コアのITプラクティスについて何をすべきか、すべきでないかについてのガイダンスとコーチングを提供します。
しかし、サプライチェーンがサプライチェーンの意思決定を所有する必要があります。サプライチェーンの意思決定を生成するすべての装置を所有する必要があります。それが彼らのコアの所有権です。前の講義で、サプライチェーンサイエンティストを定義するものは何かと言いました。サプライチェーンサイエンティストは、コードによって生成された数値的な意思決定を所有する人です。それは意思決定を生成するシステムではなく、1人または複数のサプライチェーンサイエンティストによって書き留められた数値的なレシピです。そして、それらのサプライチェーンサイエンティストは、それらの数値的な意思決定を共同で所有します。彼らはそれに所有権を持ち、サプライチェーンの責任は会社のすべての意思決定が一貫していることを確認することです。もしプロモーションや大規模なマーケティングプッシュが行われている場合、物事は時間通りに提供されるように生産される必要があります。在庫切れの状況になってから何かを押し出すことは避けたいです。在庫がないか、製造やサービスの能力がないために販売できないものに対してマーケティングプッシュにお金を使うことはありません。
title: “IT部門の理想的なビジョン”
IT部門は、チケットを渡す部門ではありません。それはうまくいかない方法ではありません。IT部門は、コアインフラストラクチャを担当しています。それは常にシームレスに動作するものです。Wi-Fiが動作しているときは気にも留めません。Wi-Fiには気を付けません。Wi-Fiが動作していないときにのみ、Wi-Fiに注意を払います。良いIT部門は、インフラストラクチャを提供してくれるので、彼らに気を付ける必要すらありません。彼らが存在することさえ気づかないほど、うまく機能します。メールも完璧に動作するように。それが良いコアITの役割です。そして、ITはあなたのところにやってきて、あなたが手助けできるような実践を確立するのを手伝ってくれる人々です。プログラム可能なロジックは少し難しいので、プログラミングのスキルを少し向上させるための指導をどこで受けるかという問題があります。答えはITであるべきです。彼らは「私たちがあなたのためにコードを書きます」と言うのではなく、「実際にそれを実装できるように指導します。いくつかの概念を手伝い、少し技術的な部分を手伝います」と言うべきです。時には、偶発的な複雑さが発生することもありますので、ITはあなたをサポートするために存在しています。しかし、基本的には、彼らはあなたのために仕事をするために存在しているわけではありません。彼らはメンターでありコーチであり、会社全体がランサムウェアのリスクやシステム的なリスクにさらされるような致命的なミスを com
結論として、従来のサプライチェーン管理の側面からは2つの課題があります。おそらくエクセルスプレッドシートの端でプログラミングを行っていたかもしれませんが、それが既にプログラミングの一形態であることに最初は気づいていなかったかもしれません。恐怖心を克服しなければなりません。明日の世界、あなたの部門はソフトウェア製品のように動作する製品を提供する責任を持つことになります。これは非常に大きな変化です。しかし、対処できるものです。なぜなら、適切なツールがあれば、プログラミングが関与することはありますが、基本的にはエクセルよりも難しいわけではありません。再び、課題はツールの技術的な難しさではなく、サプライチェーン自体の複雑さにあります。問題は、ツールの扱いが難しいからではなく、最初から複雑なサプライチェーンを持っているからです。
データサイエンティスト側またはIT側の一部の視聴者にとって、克服しなければならないのは過信です。私は何度も何度も、データサイエンティスト、そして私自身も含まれるこのカテゴリーの人々が、プロトタイプを本番環境に持っていく能力に過信していたことを目にしてきました。これは困難ですし、サプライチェーンは最も驚くべき方法で破綻する可能性があります。数年前、私たちは主要なヨーロッパの自動車部品の電子商取引会社と取引を始めました。私たちは予測技術を使って彼らの部品の補充を処理し、部品の補充に関する提案を行っていました。次の週、私たちはすべての予測が2倍になっていることに気付きました。需要が倍増していました。何が起こったかというと、彼らの主要な競合他社が同時に複数の国に進出することを決定しました。まさに私たちが予測を開始している時点で、競合他社の1つがすべての国のテレビに出演し、オンラインでサービスを開始しました。興味深いことに、私のクライアントはそれに気付いていなかったし、彼らはより優れた検索エンジン最適化の結果を出していました。彼らはSEOの面で最適化されていましたので、基本的には人々は競合他社のテレビ広告を見ていましたが、競合他社の名前を自然に覚えていなかったのです。そのため、Googleで「自動車部品」と入力して、最終的に私のクライアントのウェブサイトにたどり着いたのです。Lokadがどれほど素晴らしいかを示すために、最初の週には2倍になっていました。そして、私たちは「一体何が起こっているのか？」と考えなければなりませんでした。すべてが倍になるわけではありません。一部のものは10倍になり、多くのものは変わらないのです。
それがそのようなものであり、迅速に対応できる必要があります。それが重要です：恐怖心と過信です。お時間をいただき、ありがとうございました。
さて、チャットを通じて質問を見ていきます。
質問: 明日のためにもっと必要な場合、ソフトウェアはどのサプライヤーに追加の注文をするかを決定できますか？たとえば、オーストラリアのオフィスの200グラムのイチゴのパックは、同じ日に同じ製品を配送センターに届ける10のサプライヤーがあります。
絶対にできます。ここでは、サプライチェーン管理とサプライチェーン最適化の2つの側面を区別する必要があります。まず、サプライチェーン管理の側面では、EDIを含むすべてのデータパイプラインを備えていることが重要です。これにより、人間の介入なしでサプライヤーに電子注文を送信できる電子的な橋ができます。つまり、エンドツーエンドで電子的な橋ができます。しかし、その場合、最適化の側面では、一日中連続して実行されるソフトウェアが必要であり、ある時点で管理側に通知し、「この注文を実行してください」と伝えることができます。そして、管理側はITによって管理され、この注文が完全に実行されることを確認します。これは純粋にトランザクションの問題であり、もはや知能はありません。注文が「この数量」という指示を受け取り、生成された数量が、これらの製品を提供する資格のある正確なサプライヤーのリスト、在庫が残っているかどうか、競合するサプライヤーの中から適切な選択をする方法など、すべての制約に準拠していることを最適化側が責任を持つのです。さまざまなことが起こるかもしれません。絶対にできますが、必要な追加注文を再発注するときに、サプライチェーン管理の側面にある日常的な実行と、最適化の要素を明確に分ける必要があります。
質問: あなたは、現在eスポーツワールドチャンピオンシップと競合していることを知っていますか？
いいえ、私は現在それらのeスポーツチャンピオンシップと競合していませんが、それはとてもクールです。ところで、Lokadでは頻繁にDota 2をプレイしていますので、経営陣もプレイしています。私たちの従業員の中にはLeague of Legendsをプレイしたいという人もいますが、会社のCEOとして、私は断固として反対しています。
質問: 多くの企業が最初からERPやWMSを持っていないことを見てきましたが、経営陣はサプライチェーンの最適化に取り組んでいます。
まったくその通りです。最初の日からサプライチェーンの最適化を避けることはできません。そのような決定をしなければなりません。サプライチェーンの最適化は、サプライチェーン管理ソフトウェアが導入される前から存在していました。60年前にはソフトウェアがなかった時代でも、人々は決定をしなければなりませんでした。ですので、サプライチェーンの最適化はすでに存在しており、人々はペンと紙を使ってそれを行っていました。最も古いサプライチェーンの研究であるウィルソンの式（EOQ式とも呼ばれる）などを見れば、それは100年以上前のものです。それは明らかにソフトウェアよりも前に存在していました。ですので、組織内にソフトウェアがあるかどうかに関係なく、サプライチェーンの最適化は最初の日から行われるものです。
今では適切なITシステムを持つ必要がありますが、それはまったく異なる考え方です。サプライチェーン管理は、データ入力などの非常に単調なタスクを非常にうまく行うことに関するものです。バーコードなどのサポートも可能です。しかし、それは単にデータを表現するだけのものです。問題は、人々がサプライチェーン管理とサプライチェーンの最適化の両方を行うものを望んでいることです。その結果、通常は非常に複雑でバグだらけの製品ができあがり、アラートや例外などの悪い機能が必要になりますが、これらは避けるべきです。後の講義でそれについて詳しく説明します。
基本的には、現在WMSやERPを導入することは、すでにそれを持っていない場合、数週間の問題です。すでにそれを持っている場合、それを決定から切り離すことができれば、数か月の問題です。
質問: ビジネスの経営陣は、情報の追跡からサプライチェーンの最適化に移行する時期をどのように認識できるのでしょうか？
まず最初に、まず最初に、2つの問題があることを認識しなければなりません。そして、同じソフトウェアが両方の側面を解決することは決してありません。これが大きな幻想であり、ソフトウェアベンダーはこの分野で非常に混乱させてきました。最大のERPベンダーを見てみると、彼らのメッセージはサプライチェーンの最適化についてですが、実際に提供しているものや製品が行っていることは、サプライチェーン管理の側面にあります。AIや実際の知識がないため、それははるかに魅力的ではありません。ソフトウェアの世界では、これはCRUDアプリ（Create、Read、Update、Delete）として知られています。ERPは、リレーショナルデータベースから行を作成、読み取り、更新、削除することができる数千のCRUD画面の巨大なコレクションです。基本的には、ERPはさまざまなエンティティのための数千のテーブルのコレクションです。論理的にグループ化できるエンティティごとに、1つまたは2つの画面があります。ですので、ERPベンダーのパンフレットを読んでいる場合、マネージャーであれば、この製品はあなたのサプライチェーンを最適化すると言っていますが、答えは「いいえ、まったくそうではありません」となります。それが行うことは、生産性を向上させ、サプライチェーンの正確な帳簿を確保することです。これにより、盗難、縮小、紛失した商品の削減、倉庫でのバーコードによる生産性の向上などが劇的に実現できます。これらの製品には非常に多くの付加価値があります。ERPやWMSが持ち込む価値を軽視しているわけではありません。それは非常に大きな価値ですが、サプライチェーンの最適化についてはありません。例えば、WMSは倉庫に関心を持つものであり、顧客やサプライヤーを含む全体のサプライチェーンには関心を持ちません。それは設計上、特定の場所に焦点を当てていますが、全体のチェーンには関心を持ちません。
質問: PythonからEnvisionにスムーズに移行するにはどうすればよいですか？または、それらを一緒に使用するにはどうすればよいですか？
過去にいくつかの状況でそれらを一緒に使用してきました。聴衆の皆さんにとって、EnvisionはLokadが設計したドメイン固有のプログラミング言語で、サプライチェーンの予測最適化に特化して開発されています。次の講義では、Envisionを実際のコードの一部を使ってよりよく理解していただけるようにデモンストレーションします。
過去には、Envisionの機能が非常に限定されていたため、多くの機能が欠けており、多くの場面でPythonをデフォルトにしていました。しかし、年月が経つにつれて、Envisionの機能を徐々に拡張してきたため、Pythonのコンポーネントを必要とする必要性を段階的に排除してきました。Pythonのコンポーネントだけでなく、Airflowのように組み合わせる必要があるツールのシリーズも同様です。
ちなみに、Envisionの構文は意図的にPythonと多くの側面で整合しています。Pythonプログラマーと敵対しないように、Envisionの構文を設計する際に意識的な選択をしました。つまり、Pythonに詳しい場合は1週間でEnvisionを学ぶことができます。微妙で深い違いはあるものの、構文的には多くの共通点があります。Pythonにはシンプルさや設計の純粋さなど、多くの長所があります。Pythonが全ての要件を満たさず、回復不可能な重大な問題を引き起こすと言っても、Pythonには長所がないわけではありません。私はPythonには多くの長所があると考えています。再度言いますが、私たちは具体的にはサプライチェーンを本番環境で実行する方法について話しています。それは非常に具体的な問題です。
質問: クライアントに自分のERPが何も最適化していないことを理解させるにはどうすればよいですか？
それは非常に難しいです。率直に言うと、最悪の場合は見込み客が私に対して「私たちのERPは価値を提供していません。そして、今度はサプライチェーンの最適化を提供する次のERPに移行したいのです。」と言ってくる場合です。それは私にとって非常に困難な状況です。なぜなら、クライアントに彼らが探しているのは1つの製品ではなく2つであることを伝えなければならないからです。1つは彼らのERPを置き換え、管理面をより良く処理するものであり、もう1つは最適化を行うものです。
それらの旧式のERPについて考えると、私はそれらに非常に敬意を持っています。特に、古いIBMメインフレーム上のコマンドライン端末を持つAS/400製品についてはそうです。問題の管理面から見ると、通常非常に適切な仕事をしています。クライアントが本当に求めているものは、コマンドラインではなくウェブインターフェースかもしれませんが、それによって現場のチームがより生産的になるでしょうか？それには疑問を投げかけます。テキスト端末を持つコマンドラインは、非常に素早く、ゼロの邪魔をすることなく生産的になることができます。
ですので、私たちは競合他社が押し付ける無駄なことをすべて解明しなければなりません。その上で、ERPがサプライチェーンを最適化しないこと、AIやブロックチェーンなどは存在せず、統計モデルのクラスしかないことを説明しなければなりません。残念ながら、この段階でほとんどの見込み客を失います。それが私が最初にこれらの講義を行っている理由の1つです。問題の本質を私のように見る必要があることを説明するには時間がかかります。
質問: 複数の製品の計画を確率的な需要分布で処理するためのプラットフォームのおすすめは何ですか？
もちろん、Lokadです。ただし、私はLokadのCEOであり、同社の大株主でもあるため、私の意見には利益相反があります。Lokadが必要なプラットフォームであると深く確信していますが、それは私が所有し運営している会社でもあります。それについて客観的な意見を持ち続けるために、最善を尽くします。
ちなみに、Lokadは確率的な需要分布に対処するために文字通り設計されています。確率的な需要分布だけでなく、確率的なリードタイム分布、確率的な返品分布などにも対応しています。すべての可能な未来を確率で考慮し、あらゆる種類の不確実性を考慮する必要があります。需要は非常に重要な要素であり、通常は最も重要な要素ですが、それだけではありません。
すべての質問に答えたと思います。もし何か見落としていたら…追加の質問はありません。この講義をご視聴いただき、ありがとうございました。また来週、同じ日、同じ時間にお会いしましょう。それでは、またお会いしましょう。さようなら。
参考文献
- Joel on Software: ソフトウェア開発者、デザイナー、マネージャーに興味を持つ人々、そして彼らと何らかの関わりを持つ人々にとって興味深いさまざまな関連事項について - Joel Spolsky著、2004年
