00:00 イントロダクション
02:52 バックグラウンドと免責事項
07:39 純粋な合理主義
13:14 これまでのストーリー
16:37 私たちは科学者が必要です！
18:25 人間+機械（問題1/4）
23:16 セットアップ（問題2/4）
26:44 メンテナンス（問題3/4）
30:02 ITの遅れ（問題4/4）
32:56 ミッション（科学者の仕事1/6）
35:58 用語（科学者の仕事2/6）
37:54 成果物（科学者の仕事3/6）
41:11 スコープ（科学者の仕事4/6）
44:59 日常業務（科学者の仕事5/6）
46:58 所有権（科学者の仕事6/6）
49:25 サプライチェーンのポジション（人事1/6）
51:13 科学者の採用（人事2/6）
53:58 科学者のトレーニング（人事3/6）
55:43 科学者のレビュー（人事4/6）
57:24 科学者の定着（人事5/6）
59:37 次の科学者へ（人事6/6）
01:01:17 ITについて（企業のダイナミクス1/3）
01:03:50 財務について（企業のダイナミクス2/3）
01:05:42 リーダーシップについて（企業のダイナミクス3/3）
01:09:18 旧来の計画（近代化1/5）
01:11:56 S&OPの終了（近代化2/5）
01:13:31 旧来のBI（近代化3/5）
01:15:24 データサイエンスの終了（近代化4/5）
01:17:28 ITのための新しい取引（近代化5/5）
01:19:28 結論
01:22:05 7.3 サプライチェーンサイエンティスト - 質問はありますか？
説明
量的サプライチェーンイニシアチブの中核には、サプライチェーンサイエンティスト（SCS）がいます。SCSは、データの準備、経済モデリング、KPIレポートの実行を行います。サプライチェーンの意思決定のスマートな自動化は、SCSによって行われた作業の結果です。SCSは生成された意思決定の所有権を持ちます。SCSは、機械処理能力を通じて拡大された人間の知性を提供します。
フルトランスクリプト
この一連のサプライチェーン講義へようこそ。私はジョアネス・ヴェルモレルです。今日は、量的サプライチェーンの観点からサプライチェーンサイエンティストを紹介します。サプライチェーンサイエンティストは、サプライチェーンイニシアチブを主導する人物、または可能性があれば小さなグループの担当者です。この人物は、興味のある意思決定を生成するための数値レシピの作成と後の維持を監督します。また、この人物は、生成された意思決定が妥当であることを会社の他のメンバーに証明するための必要な証拠を提供する責任も担っています。
量的サプライチェーンのモットーは、現代のハードウェアとソフトウェアがサプライチェーンに提供するものを最大限に活用することです。しかし、この視点の具体的な味付けは素朴です。人間の知性はまだサプライチェーンに関してはうまくパッケージ化されていません。この講義の目的は、なぜサプライチェーンサイエンティストの役割が、過去10年間で現代のソフトウェアをサプライチェン目的に最大限に活用するための確立された解決策になったのかを理解することです。
この目標を達成するためには、現代のソフトウェアがサプライチェンの自動化を試みる際に直面している大きなボトルネックを理解することから始めます。この新たな理解に基づいて、ボトルネックに対する答えとしてのサプライチェーンサイエンティストの役割を紹介します。最後に、この役割が会社全体を小さな変化や大きな変化でどのように再構築するかを見ていきます。実際、サプライチェーンサイエンティストは会社内の「サイロ」としては機能しません。科学者が何かを達成するためには、会社の他のメンバーと協力する必要がありますし、会社の他のメンバーも科学者と協力する必要があります。
さらに進む前に、このシリーズの最初の講義で述べた免責事項を再確認したいと思います。この講義は、サプライチェーン最適化に特化したエンタープライズソフトウェアベンダーであるLokadで行われた10年間にわたる独自の実験に基づいています。これらの講義はすべて、Lokadの旅によって形作られていますが、サプライチェーンサイエンティストの役割に関しては、その結びつきはさらに強いです。大いに言えることですが、Lokad自体の旅は、サプライチェーンサイエンティストの役割の発見を通じて読むことができます。
このプロセスはまだ進行中です。たとえば、私たちは約5年前に、学習と最適化のためのプログラミングパラダイムの導入により、主流のデータサイエンティストの視点を諦めました。Lokadは現在、3ダースのサプライチェーンサイエンティストを雇用しています。私たちの最も能力のある科学者は、彼らの実績を通じて大規模な意思決定に信頼されています。彼らの中には、数億ドル以上の在庫に関するパラメーターの個別の責任を持つ人もいます。この信頼は、発注、生産発注、在庫割り当て発注、価格設定など、さまざまな意思決定に及びます。
この信頼を得るには、長年のプロセスが必要であることは容易に想像できるでしょう。実際、ほとんどの企業は、Lokadのようなサードパーティのベンダーにさえ、このような権限を持つことを信頼しません。この程度の信頼を得るには、技術手段に関係なく通常数年かかります。それにもかかわらず、10年後、Lokadは設立当初よりも速く成長しており、既存の顧客からの成長のかなりの部分は、Lokadに信頼される意思決定の範囲を広げている顧客からもたらされています。
これが私の最初のポイントに戻ります。この講義には、間違いなくさまざまなバイアスが含まれているでしょう。私はLokad以外の類似の経験を通じてこの視点を広げようと努力しましたが、その点ではあまり話すことはありません。私の知る限り、いくつかのテックジャイアント企業、特にいくつかの巨大な電子商取引企業は、Lokadが達成する意思決定の自動化の度合いに匹敵するものを実現しています。
ただし、これらの巨大企業は通常、通常の大企業が負担できる2桁以上のリソースを割り当てており、エンジニアリングの人員数は数百人です。これらのアプローチの実現可能性は私には不明ですが、これらのアプローチは非常に利益の高い企業でのみ機能する可能性があります。そうでない場合、驚異的な給与コストは、より良いサプライチェーンの実行にもたらされる利益を上回る可能性があります。
さらに、このような規模でエンジニアリングの才能を引き付けること自体が課題となります。優れたソフトウェアエンジニアを1人雇うことは十分に困難ですが、その100倍の人材を雇うには非常に優れた雇用主のブランドが必要です。幸いなことに、今日のプレゼンテーションははるかにシンプルです。Lokadによって実施される多くのサプライチェーンの取り組みは、1人のサプライチェーンサイエンティストと、代わりに行動する2人目のサイエンティストで行われています。給与の節約に加えて、私たちの経験からは、少人数の人員に関連する重要なサプライチェーンの利点があることが示されています。
主流のサプライチェーンの視点は、応用数学の立場を取っています。方法とアルゴリズムは、人間のオペレーターを完全に排除した形で提示されます。たとえば、安全在庫の計算式や経済的発注量の計算式は、純粋な応用数学の問題として提示されます。これらの式を扱う人物の身元、スキル、バックグラウンドなどは、重要ではないだけでなく、プレゼンテーションの一部でもありません。
より一般的には、この立場はサプライチェーンの教科書やそれに基づくソフトウェアで広く採用されています。人間の要素を絵から取り除くことは、より客観的に感じられるでしょう。結局のところ、定理の妥当性は証明を述べる人物に依存しないし、アルゴリズムのパフォーマンスも、最後のキーストロークを押す人物に依存しません。このアプローチは、優れた形の合理性を達成することを目指しています。
しかし、私はこの立場が単純であり、単なる単純な合理主義の別の例であると主張します。私の提案は微妙ですが重要です。数値的なレシピの結果が最終的に実行する人物に依存するとは主張していませんし、数学者の性格が彼らの定理の妥当性と何ら関係があるわけでもありません。私の提案は、この視点に関連する知的な立場がサプライチェーンに取り組むためには不適切であるということです。
現実のサプライチェーンのレシピは、複雑な職人技の一部であり、レシピの作者は見かけほど中立で無関係ではありません。変数の名前だけが異なる2つの同一の数値レシピを考えて、このポイントを説明しましょう。数値レベルでは、2つのレシピは同じ出力を提供します。しかし、最初のレシピは適切に選ばれた意味のある変数名を持っている一方、2番目のレシピは意味不明で一貫性のない名前を持っています。実際、2番目のレシピ（意味不明で一貫性のない変数名を持つレシピ）は、起こることを待っている災害です。2番目のレシピに適用されるすべての進化やバグ修正は、最初のレシピで実行される同じタスクに比べて桁違いに努力が必要です。実際、変数の名前の問題は非常に頻繁で深刻であり、多くのソフトウェアエンジニアリングの教科書がこの1つの問題に完全な章を割いています。
数学、アルゴリズム、統計は変数名の適切さについて何も言いません。それらの名前の適切さは明らかに見る人の目にかかっています。2つの数値的に同一のレシピがありますが、主観的な理由から、1つは他よりもはるかに優れていると見なされます。ここで私が擁護している提案は、主観的な懸念にも合理性があるということです。これらの懸念は、主体や人物に依存しているために完全に無視されるべきではありません。むしろ、Lokadの経験は、同じソフトウェアツール、数学的な手法、アルゴリズムのライブラリを提供された場合、特定のサプライチェーンの科学者が優れた結果を達成することを示しています。実際、担当する科学者の身元は、イニシアチブの成功の最も良い予測因子の1つです。
サプライチェーンの成功の相違を完全に説明するのに生まれつきの才能だけではないと仮定すると、客観的または主観的な要素に貢献する要素を受け入れるべきです。これが、Lokadでは、過去数十年間にわたってサプライチェーン科学者の役割に対するアプローチを洗練するために多くの努力を払ってきた理由です。サプライチェーン科学者の立場に関連する微妙な要素は過小評価されるべきではありません。これらの主観的な要素によってもたらされる改善の大きさは、私たちの最も注目すべき技術的な成果に匹敵します。
この講義シリーズは、Lokadのサプライチェーン科学者のためのトレーニング教材として意図されています。ただし、サプライチェーンの実践者やサプライチェーンの学生など、より広い視聴者にも興味を持ってもらえることを願っています。サプライチェーン科学者が取り組んでいる内容を徹底的に理解するためには、これらの講義を順番に見ることが最適です。
第1章では、なぜサプライチェーンがプログラム化され、数値レシピを本番環境に配置できることが非常に望ましいのかを見てきました。サプライチェーンのますます複雑化により、自動化は以前以上に重要になっています。さらに、サプライチェーンの実践を資本主義的にするための財務的な必要性があります。
第2章は方法論に dedicat されています。サプライチェーンは競争的なシステムであり、この組み合わせは単純な方法論を打ち負かします。科学者の役割は、単純な応用数学の方法論に対する解毒剤と見なすことができます。
第3章では、サプライチェーンの人員が直面する問題について調査しています。この章では、対処する必要がある意思決定の課題のクラスを特徴付けようと試みています。すべてのSKUに適切な在庫数量を選ぶなどの単純化された視点は、現実世界の状況には適合しません。意思決定の形式には必ず深さがあります。
第4章では、ソフトウェア要素が普及している現代のサプライチェーンの実践を理解するために必要な要素を調査しています。これらの要素は、デジタルサプライチェーンが運営する広範なコンテキストを理解するために基本的です。
第5章と第6章は、予測モデリングと意思決定に dedicat されています。これらの章では、機械学習と数理最適化を特集して、数値レシピの「スマート」な部分をカバーしています。特に、これらの章では、サプライチェーン科学者の手によってうまく機能するとわかった技術を収集しています。
最後に、第7章である現在の章は、数量的なサプライチェーンの取り組みの実行に dedicat されています。私たちは、適切な基盤を整えながら取り組みを開始するために必要なことを見てきました。数値レシピを実際に製品化し、ゴールに到達する方法を見てきました。
今日は、この全体を実現するためにどのような人物が必要かを見ていきます。
科学者の役割は、学術文献で見つかる問題を解決することを目指しています。サプライチェーン科学者の仕事、ミッション、範囲、日常のルーティン、興味の対象について見直していきます。この職務の説明は、Lokad の現在の実践を反映しています。
会社内での新しいポジションは、さまざまな懸念を引き起こすため、科学者は雇用、訓練、レビュー、維持する必要があります。人事の観点からこれらの懸念に取り組んでいきます。科学者は、サプライチェーン部門を超えて会社の他の部門と協力することが期待されています。科学者とIT、財務、さらには会社のリーダーシップの間で期待される相互作用について見ていきます。
科学者は、会社のスタッフと業務を近代化する機会でもあります。この近代化は既存のポジションを廃止することよりも新しいポジションを導入することの方がはるかに困難です。
この講義シリーズで私たちが設定した課題は、数量的手法を通じてサプライチェーンの体系的な改善です。このアプローチの一般的な要点は、現代のコンピューティングとソフトウェアがサプライチェーンに提供するものを最大限に活用することです。ただし、人間の知性の領域と成功裏に自動化できる領域を明確にする必要があります。
人間の知性と自動化の境界線は、まだ技術に大きく依存しています。優れた技術は、より幅広い範囲の意思決定を機械化し、より良い結果を提供することが期待されています。サプライチェーンの観点からは、在庫の補充の意思決定に加えて価格の意思決定など、より多様な意思決定を行い、会社の収益性をさらに向上させることを意味します。
科学者の役割は、人間の知性と自動化の境界線の具現化です。人工知能に関する日常的な発表が人間の知性が自動化される寸前であるという印象を与えるかもしれませんが、私の理解では、一般的な人工知能はまだ遠い存在です。実際、サプライチェーンの関連性を持つ数量的手法の設計においては、人間の洞察力がまだ非常に重要です。基本的なサプライチェーン戦略の確立は、ソフトウェアが提供できる範囲を大きく超えています。
より一般的には、サプライチェーンには問題のフレームが不適切であるか、特定されていない問題を解決するための技術はまだありません。ただし、狭い、明確に定義された問題が分離された場合、自動化プロセスがその解決策を学習し、人間の監視なしでこの解決策を自動化することは考えられます。
この視点は新しいものではありません。たとえば、迷惑メールフィルターは広く採用されています。これらのフィルターは、関連するものと関連しないものを分類するという困難なタスクを達成しています。ただし、次世代のフィルターの設計は、新しいデータを使用してこれらのフィルターを更新することができるとしても、主に人間に任されています。実際、迷惑メールフィルターを回避したいスパマーは、これらのフィルターの単なるデータ駆動の更新を打破する新しい方法を常に考案しています。
したがって、自動化をエンジニアリングするためには人間の洞察力が必要ですが、Lokad のようなソフトウェアベンダーが、例えば、これらのすべての課題に対処する大規模なサプライチェーンエンジンをエンジニアリングできない理由は明確ではありません。確かに、ソフトウェアの経済学は、このような大規模なサプライチェーンエンジンを多くの企業に再販することで、ライセンス料で大金を稼ぐことを非常に支持しています。初期投資は高額かもしれませんが、ソフトウェアは無視できるコストで複製できるため、ベンダーは多くの企業にこの大規模なエンジンを再販することで大金を稼ぐことができます。
2008年、Lokad はパッケージ化されたソフトウェア製品として展開できる大規模なエンジンの作成に取り組みました。より具体的には、Lokad は当時、大規模なサプライチェーンエンジンではなく、大規模な予測エンジンに焦点を当てていました。しかし、予測はグローバルなサプライチェーンの課題のほんの一部に過ぎないため、Lokad はこのような大規模な予測エンジンの作成に失敗しました。この講義シリーズで提示される数量的なサプライチェーンの視点は、この大規模なエンジンの野望の破綻から生まれました。
サプライチェーンに関しては、解決すべき3つの大きなボトルネックがあることがわかりました。この大規模なエンジンが最初から失敗する理由と、このようなエンジニアリングの偉業にはおそらく数十年かかるという理由を見ていきましょう。
典型的なサプライチェーンのアプリケーションの風景は、過去20年から30年にわたって無秩序に成長したジャングルです。この風景は整然とした幾何学的なラインと手入れの行き届いた茂みのあるフランス式庭園ではありません。それはジャングルであり、活気に満ちていますが、とげと敵意を持った生物もいます。より深刻なことに、サプライチェーンはそのデジタルの歴史の産物です。複数の半冗長なERP、半完成の自社開発のカスタマイズ、バッチの統合、特に買収した企業からのシステムとの重複したソフトウェアプラットフォームなど、同じ機能領域を競合するソフトウェアプラットフォームが存在する場合があります。
ある大規模なエンジンを簡単に接続できるという考えは、現在のソフトウェア技術の状態を考えると幻想的です。サプライチェーンを操作するすべてのシステムを結びつけることは、完全に人間のエンジニアリングの努力に依存する大きな作業です。
集合的な費用の分析によれば、データの整理はサプライチェーンの取り組みに関連する全体的な技術的な努力の少なくとも3/4を占めています。対照的に、予測や最適化などの数値レシピのスマートな側面を作り上げることは、全体的な努力のわずか数パーセントに過ぎません。したがって、パッケージ化された大規模なエンジンの利用可能性は、コストや遅延の観点からはほとんど重要ではありません。サプライチェーンで一般的に見られる無秩序なITランドスケープに自動的に統合するためには、このエンジンに組み込まれた人間レベルの知能が必要です。
さらに、大規模なエンジンはその存在により、この作業をさらに困難にします。複雑なシステムであるアプリケーションの風景と大規模なエンジンの2つの複雑なシステムを扱うことになります。これら2つのシステムを統合する複雑さは、それぞれの複雑さの合計ではなく、その複雑さの積です。
この複雑さがエンジニアリングコストに与える影響は非常に非線形です。これは、この講義シリーズの第1章で既に述べられているポイントです。サプライチェーンの最初の主要なボトルネックは数値レシピの設定であり、専任のエンジニアリングの努力が必要です。このボトルネックにより、パッケージ化された大規模なサプライチェーンエンジンに関連付けられる可能性のある利点はほぼ排除されます。
設定にはかなりのエンジニアリングの努力が必要かもしれませんが、それは一度きりの投資であり、入場券を支払うのと同じです。残念なことに、サプライチェーンは絶えず進化する生きた存在です。サプライチェーンが変化しなくなる日は、会社が破産する日です。変更は内部的なものと外部的なものの両方です。
内部的には、アプリケーションの風景は常に変化しています。企業は、エンタープライズソフトウェアベンダーによって要求される多くのアップグレードがあるため、アプリケーションの風景を凍結することはできません。これらの要件を無視すると、ベンダーは契約上の義務から解放されることになり、これは受け入れられない結果です。純粋に技術的なアップデートを超えて、企業自体が変化するにつれて、サプライチェーンはソフトウェアの一部を導入し、廃止することになります。
外部的には、市場も絶えず変化しています。新しい競合他社、販売チャネル、潜在的なサプライヤーが現れ、一部は消えていきます。規制も変化し続けています。アルゴリズムは、製品クラスの需要の成長など、いくつかの明確な変化を自動的に捉えるかもしれませんが、単に大きさではなく種類の変化に対処するアルゴリズムはまだありません。サプライチェーン最適化が対処しようとする課題自体も変化しています。
もしサプライチェーン最適化のためのソフトウェアがこれらの変化に対処できない場合、従業員はスプレッドシートに頼ることになります。スプレッドシートは粗雑かもしれませんが、少なくとも従業員はそれらを手元のタスクに関連付けることができます。事実、意思決定レベルでは、サプライチェーンのほとんどがスプレッドシートを使用して動作していると言われています。これはソフトウェアのメンテナンスが失敗していることの生きた証拠です。
1980年代以来、企業向けソフトウェアベンダーはサプライチェーンの意思決定を自動化するためのソフトウェア製品を提供してきました。大規模なサプライチェーンを運営する多くの企業は、過去数十年にわたりこれらのソリューションのいくつかをすでに導入しています。しかし、従業員はいつもスプレッドシートに戻ってしまい、最初は成功と見なされた設定に何か問題があったことを証明しています。
メンテナンスはサプライチェーン最適化の第2の大きなボトルネックです。実行はほとんど放置できるかもしれませんが、積極的なメンテナンスが必要です。
この時点で、サプライチェーン最適化には初期のソフトウェアエンジニアリングリソースだけでなく、継続的なソフトウェアエンジニアリングリソースも必要であることが示されています。このシリーズの講義で以前に指摘されたように、現実のサプライチェーンが直面する多様な問題には、プログラムの能力しか現実的に対応できません。スプレッドシートはプログラム可能なツールとして数えられ、ボタンやメニューとは異なる表現力がサプライチェーンの実践者にとって魅力的な要素です。
ソフトウェアエンジニアリングリソースはほとんどの企業で確保されなければなりませんので、IT部門に頼るのは自然なことです。残念ながら、サプライチェーンだけでなく、営業、マーケティング、財務など、すべての部門がこの考え方を持っています。それらの各部門は、それぞれの意思決定プロセスを自動化するためにソフトウェアエンジニアリングリソースを必要とします。さらに、トランザクションレイヤーとその基盤全体にも対応する必要があります。
その結果、現在の大規模なサプライチェーンを運営する多くの企業は、IT部門が数年間のバックログに埋もれている状況です。したがって、IT部門にさらなる継続的なリソースを割り当てることを期待することは、バックログを悪化させるだけです。IT部門へのリソースの追加オプションは既に検討されており、通常はもはや実行可能ではありません。これらの企業は、IT部門に関しては深刻な規模の経済効果の逆転に直面しています。ITのバックログは、サプライチェーン最適化における第3の大きなボトルネックを表しています。
継続的なエンジニアリングリソースは必要ですが、その大部分はITからは提供できません。ITからの一部のサポートは想定できますが、それは控えめなものでなければなりません。
これらの3つの大きなボトルネックが、なぜ特定の役割が必要なのかを定義しています。サプライチェーンサイエンティストという名前を付けているのは、サプライチェーンの日常的な意思決定と要求の厳しい意思決定プロセスを自動化するために必要な継続的なソフトウェアエンジニアリングリソースを指しています。
ロカッドの実践に基づいて、より正確な定義を進めましょう。サプライチェーンサイエンティストのミッションは、サプライチェーンを運営するために日々必要な日常的な意思決定を生成する数値レシピを作り出すことです。サイエンティストの仕事は、アプリケーションの全体から収集されたデータベースの抽出から始まります。サイエンティストは、それらのデータベースの抽出を処理するレシピをコーディングし、それらのレシピを本番環境に持ち込むことが期待されています。サイエンティストは、レシピによって生成される意思決定の品質に完全な責任を負います。意思決定はある種の周囲のシステムによって生成されるのではなく、サイエンティストの洞察力を通じてレシピを通じて直接表現されるものです。
この一つの側面は、通常のデータサイエンティストの役割とは大きく異なる重要な点です。しかし、ミッションはそこで終わりません。サプライチェーンサイエンティストは、レシピによって生成されたすべての意思決定を支持する証拠を提示できることが期待されています。意思決定の責任は不透明なシステムにあるのではなく、人、つまりサイエンティストにあります。サイエンティストは、サプライチェーンのリーダーやCEOと会って、レシピによって生成されたどの意思決定にも納得のいく根拠を提供できるはずです。
もしサイエンティストが会社に大きな損害を与える可能性がない立場にいるのであれば、何かがおかしいです。私は誰に対しても、特にサイエンティストに対して、監督や責任を持たないまま大きな権限を与えることを提唱しているわけではありません。私は単に明らかなことを指摘しているだけです。つまり、あなたがどれほどパフォーマンスが悪くても、会社に悪影響を与える力がなければ、どれほど優れたパフォーマンスをしても、会社に良い影響を与える力はありません。
大企業は残念ながらリスク回避志向です。そのため、サイエンティストをアナリストに置き換えることは非常に誘惑的です。意思決定そのものを担当するサイエンティストとは異なり、アナリストはあちこちに光を当てることだけが責任です。アナリストはほとんど無害で、自分の時間と一部の計算リソースを無駄にすることしかできません。しかし、無害であることがサプライチェーンサイエンティストの役割ではありません。
“サプライチェーンサイエンティスト"という用語について少し議論しましょう。残念ながら、この用語は完璧ではありません。私は約10年前にこの表現を「データサイエンティスト」のバリエーションとして考案しました。つまり、この役割をデータサイエンティストのバリエーションでありながら、強力なサプライチェーンの専門知識を持つ役割としてブランディングするというアイデアでした。専門化に関する洞察は正しかったのですが、データサイエンスに関する洞察は正しくありませんでした。この点については、講義の最後で再考します。
“サプライチェーンエンジニア"という言葉の方が適切だったかもしれません。なぜなら、それは純粋な理解ではなく、ドメインをマスターし制御する意欲を強調しているからです。しかし、一般的に理解されているようなエンジニアは、アクションの最前線にいることは期待されていません。適切な用語はおそらくサプライチェーンクォンティティということになるでしょう。つまり、数量的なサプライチェーンの実践者という意味です。
ファイナンスでは、クォンティティティトレーダーまたはクォンティティティトレーダーは、アルゴリズムと数量的手法を活用して取引の意思決定を行う専門家です。クォンティティティトレーダーは銀行を大いに利益をもたらすこともありますが、逆に大いに損失をもたらすこともあります。人間の知性は、良い面も悪い面も機械を通じて拡大されます。
いずれにせよ、適切な用語はコミュニティ全体で決定されることになります。アナリスト、サイエンティスト、エンジニア、オペレーター、またはクォンティティティトレーダーのいずれかです。一貫性を保つために、私はこの講義の残りで引き続き「サイエンティスト」という用語を使用します。
サイエンティストの主な成果物は、ソフトウェアの一部、より具体的には、関心のあるサプライチェーンの日々の意思決定を生成する数値レシピです。このレシピは、データの準備の初期段階から意思決定の最終段階までに関与するすべてのスクリプトのコレクションです。このレシピは本番用に作成される必要があります。つまり、監視なしで実行でき、生成される意思決定がデフォルトで信頼されるものです。もちろん、この信頼は最初に獲得する必要があり、継続的な監督によってこの信頼レベルが時間を経ても保証される必要があります。
本番用のレシピを提供することは、サプライチェーンの実践を生産的な資産に変えるために基本的な要素です。この視点は、以前の講義で製品指向のデリバリーについてすでに議論されています。
このレシピ以外にも、多くの副次的な成果物があります。それらのいくつかもソフトウェアですが、それらは直接的に意思決定の生成に貢献しない場合もあります。これには、サイエンティストがレシピ自体を作成し、後でメンテナンスするために導入する必要があるすべての計測機器が含まれます。他のアイテムは、会社内の同僚向けであり、イニシアチブ自体とレシピのすべてのドキュメンテーションを含みます。
レシピのソースコードは「どのように」に答えます。しかし、ソースコードは「なぜ」には答えません。なぜそれを行うのかは文書化される必要があります。頻繁に、レシピの正確さは意図の微妙な理解にかかっています。提供されるドキュメントは、前のサイエンティストがプロセスをサポートするために利用できない場合でも、次のサイエンティストへの円滑な移行を可能にする必要があります。
Lokadでは、標準的な手順として、イニシアチブのグランドブックである「ジョイントプロシージャマニュアル（JPM）」を作成および維持しています。このマニュアルは、レシピの完全な操作マニュアルだけでなく、サイエンティストが行ったモデリングの選択に基づくすべての戦略的な洞察のコレクションでもあります。
技術レベルでは、サイエンティストの作業は生データの抽出から最終的なサプライチェーンの意思決定の生成まで行われます。サイエンティストは既存のビジネスシステムから抽出された生データから作業を開始します。各ビジネスシステムは独自の技術スタックを持つため、抽出自体は通常、ITスペシャリストによって専任されることが最善です。サイエンティストがビジネスデータにアクセスするためにSQLの方言やAPIの技術を半ダース以上習得することは合理的ではありません。一方、ITスペシャリストにはデータの変換やデータの準備を期待することはありません。サイエンティストにアクセス可能な抽出データは、ビジネスシステム内でのデータの表現にできるだけ近いものでなければなりません。
パイプラインのもう一方の端では、サイエンティストが作成したレシピは最終的な意思決定を生成する必要があります。意思決定の展開に関連する要素は、サイエンティストの範囲外です。それらは重要ですが、意思決定自体とは大きく独立しています。例えば、発注を考慮する場合、最終的な数量の確定はサイエンティストの範囲内ですが、サプライヤが期待する注文書であるPDFファイルの生成は範囲外です。しかし、範囲は多少広いです。その結果、範囲をいくつかのサブスコープに分割することは誘惑されますが、これは誤った方法です。大企業では、この誘惑は非常に強くなり、抵抗しなければなりません。範囲を分割することは、多くの問題を引き起こす最も確実な方法です。
上流では、誰かが入力を調整してサイエンティストを助けようとすると、その試みは必ず「ゴミ入れ、ゴミ出し」の問題に終わります。ビジネスシステムは十分に複雑です。事前にデータを変換することは、余分な偶発的な複雑さを追加するだけです。中流では、誰かが予測などの難しい部分を担当してサイエンティストを助けようとすると、サイエンティストは自分自身のレシピの中でブラックボックスに直面することになります。そのようなブラックボックスは、サイエンティストのホワイトボックス化の取り組みを損ないます。そして、下流では、誰かがさらに意思決定を再最適化しようとすると、混乱が生じ、2層の最適化ロジックが相反する目的で動作する可能性さえあります。
これは、サイエンティストが一人で作業する必要があるということを意味するものではありません。サイエンティストのチームを形成することもできますが、範囲は変わりません。チームが形成された場合、レシピの共同所有権が必要です。これは、たとえば、レシピの欠陥が特定された場合、チームのメンバーは誰でもそれを修正できるということを意味します。
Lokadの経験から、サプライチェーンのサイエンティストの健全なミックスは、コーディングに40％の時間、会社の他のメンバーとの対話に30％の時間、ドキュメントの作成、トレーニング資料の作成、サプライチェーンの専門家や他のサプライチェーンのサイエンティストとの交流に30％の時間を費やすことです。
コーディングは、もちろん、レシピ自体を実装するために必要です。ただし、レシピが本番環境にある場合、コーディングのほとんどの努力は、レシピ自体ではなく、その計測に向けられます。レシピを改善するためには、さらなる洞察が必要であり、その洞察には実装する必要のある専用の計測が必要です。
会社の他のメンバーとの対話は基本的です。S&OPとは異なり、これらの議論の目的は予測を上方または下方に誘導することではありません。それは、レシピに埋め込まれたモデリングの選択が会社の戦略とすべての運用上の制約を正確に反映し続けていることを確認することです。
最後に、企業がサプライチェーン最適化について持つ機関知識を育成することが重要です。これは、科学者自身の直接的なトレーニングや同僚向けの文書の作成を通じて行われます。レシピのパフォーマンスは、科学者の能力の大きな反映です。同僚にアクセスし、フィードバックを求めることは、科学者の能力を向上させるための最も効果的な手段の1つであることは驚くべきことではありません。
Lokadが描くサプライチェーン科学者と一般的なデータサイエンティストの最大の違いは、現実の結果への個人的なコミットメントです。それは小さな、取るに足らないことのように思えるかもしれませんが、経験はそうではありません。10年前、Lokadは、本番グレードのレシピの提供へのコミットメントが当然ではないことを痛感しました。それどころか、データサイエンティストとして訓練された人々のデフォルトの態度は、本番を二の次に扱うことのように見えます。一般的なデータサイエンティストは、機械学習や数理最適化などのスマートな要素を管理することを期待しており、現実のサプライチェーンに関連するランダムなトリビアに取り組むことは、頻繁に彼らにとっては下に見えるようです。
しかし、本番グレードのレシピへのコミットメントは、最もランダムなことに対処することを意味します。たとえば、2021年7月、多くのヨーロッパの国々で壊滅的な洪水が発生しました。Lokadのドイツに拠点を置くクライアントは、倉庫の半分が浸水しました。このアカウントを担当するサプライチェーン科学者は、この深刻な状況を最大限に活用するために、レシピをほぼ一晩で再設計する必要がありました。修正は、壮大な機械学習アルゴリズムではなく、デコードされたヒューリスティックスのセットでした。逆に、サプライチェーン科学者が意思決定を所有していない場合、この人物は本番グレードのレシピを作成することはできません。これは心理的な問題です。本番グレードのレシピを提供するには、膨大な知的努力が必要であり、従業員から必要なレベルの集中を得るためには、賭けが本物でなければなりません。
サプライチェーン科学者の仕事を明確にしたので、人事の観点からその仕事の進め方について話しましょう。まず、企業の関心事の中で、科学者はサプライチェーンの責任者、または少なくともシニアサプライチェーンリーダーとして資格のある人物に報告する必要があります。Lokadのような場合、科学者が内部の人物であるか外部の人物であるかは問題ではありません。重要なのは、科学者がサプライチェーンの責任者の直接の監督下にある必要があるということです。
よくある間違いは、科学者がIT部門の責任者やデータ分析の責任者に報告することです。レシピの作成はコーディングの作業であるため、サプライチェーンのリーダーシップはそのような取り組みを完全に監督することに不安を感じるかもしれません。しかし、これは正しくありません。科学者は、生成された意思決定が受け入れ可能かどうかを承認できる人物から監督を受ける必要があります。または、少なくともこの承認を実現できる人物から監督を受ける必要があります。科学者をサプライチェーンのリーダーシップの直接の監督下以外の場所に配置することは、終わりのないプロトタイプを通じて運用し続けるためのレシピです。この状況では、役割は必然的にアナリストのものに戻り、数量化されたサプライチェーンの取り組みの最初の野心は放棄されます。
最高のサプライチェーン科学者は、平均的な科学者と比べて非常に高いリターンを生み出します。これはLokadの経験でもあり、数十年前にソフトウェア業界で特定されたパターンと一致しています。ソフトウェア企業は長い間、最高のソフトウェアエンジニアは平均的なエンジニアの少なくとも10倍の生産性を持っており、平凡なエンジニアはマイナスの生産性を持つことさえあり、コードベースに貢献する時間が増えるほどソフトウェアは悪くなります。
サプライチェーン科学者の場合、優れた能力は生産性を向上させるだけでなく、より重要なこととして、最終的なサプライチェーンのパフォーマンスを向上させます。同じソフトウェアツールと数学的な手法を使用しても、2人の科学者は同じ結果を得ることはありません。したがって、最高の科学者のポテンシャルを持つ人を採用することが非常に重要です。
Lokadの50人以上の科学者を採用した経験から、非専門のエンジニアプロフィールは通常非常に優れていることが示されています。直感に反して、データサイエンス、統計学、コンピュータサイエンスの形式的なトレーニングを受けた人々は、通常、サプライチェーン科学者のポジションには最適な適性を持っていません。これらの個人はレシピを複雑にしすぎ、サプライチェーンの日常的で重要な側面に十分な注意を払いません。多くの詳細に注意を払い、数値的な偶発的な現象を追い続ける能力が、最高の科学者の主要な資質のようです。
Lokadでは、数年間監査人として働いた若いエンジニアとの良好な実績があります。企業ファイナンスに精通していることに加えて、優れた監査人は企業の記録の海を探索する能力を開発するようです。これはサプライチェーン科学者の日常の現実と一致しています。
採用によって、採用者が適切なポテンシャルを持っていることが保証されたら、次のステップは適切にトレーニングすることです。Lokadのデフォルトの立場は、人々にサプライチェーンについて何も知らないことを期待していないということです。サプライチェーンについての知識があることはプラスですが、学界はこの点でやや不十分です。ほとんどのサプライチェーンの学位は管理とリーダーシップに焦点を当てていますが、若い卒業生にとっては、このシリーズの講義の第2章、第3章、第4章でカバーされているようなトピックの適切な基礎知識を持つことが重要です。残念ながら、これがしばしば事実ではなく、これらの学位の定量的な部分は期待を下回ることがあります。そのため、サプライチェーン科学者は雇用主によってトレーニングを受ける必要があります。この講義シリーズは、Lokadで使用されるトレーニング資料の一部を反映しています。
サプライチェーン科学者のパフォーマンスレビューは、企業の資金が適切に使われていることや昇進が決定されるなど、さまざまな理由で重要です。通常の基準が適用されます：態度、勤勉さ、熟練度など。ただし、直感に反する側面があります：最高の科学者は、サプライチェーンの課題をほとんど目立たなくする結果を達成します。
既存のレシピを維持しながら、以前のサプライチェーンのパフォーマンスレベルを維持するために科学者をトレーニングするには約6ヶ月かかります。ゼロから予測グレードのレシピを実装するために科学者をトレーニングするには約2年かかります。才能の定着は重要ですが、経験豊富なサプライチェーン科学者を採用することはまだ選択肢にありません。
多くの国では、30歳以下のソフトウェアおよび関連分野のエンジニアの中央在職期間は非常に短いです。Lokadは従業員の幸福に焦点を当てることで、より長い在職期間を実現しています。企業は従業員に幸福をもたらすことはできませんが、ばかげたプロセスを通じて従業員を不幸にすることは避けることができます。正気は従業員の定着に大いに役立ちます。
能力のある経験豊富なサプライチェーン科学者は、企業のユニークな戦略とサプライチェーンの特異性を反映したレシピをすぐに引き継ぐことはできません。最良の条件で、1つのサプライチェーンから別のサプライチェーンへの移行には約1ヶ月かかります。大規模な企業が1人の科学者に依存することは合理的ではありません。Lokadでは、2人の科学者がいつでもプロダクションで使用されるレシピに精通しています。連続性は重要であり、クライアントと共同で作成されたマニュアルを通じて、予期しない科学者間の移行を容易にすることができます。
サプライチェーン科学者の役割は、特にIT部門との協力レベルが非常に高いです。レシピの適切な実行は、データ抽出パイプラインの責任がITにあります。
最初の数量的なサプライチェーンイニシアチブの開始時には、ITと科学者の間で比較的密接な相互作用があります。この相互作用は約2〜3ヶ月続きます。その後、データ抽出パイプラインが整備されると、相互作用はより頻繁ではなくなります。この対話により、科学者はITのロードマップやサプライチェーンに影響を与えるソフトウェアのアップグレードや変更について常に把握しています。
数量的なサプライチェーンイニシアチブの初期段階では、ITと科学者の間で比較的密接な相互作用があります。最初の2〜3ヶ月間、科学者は週に数回ITと対話する必要があります。その後、データ抽出パイプラインが整備されると、相互作用はずっと頻度が低くなり、月に1回以下になります。パイプラインの偶発的な問題を解決するだけでなく、この対話により、科学者はITのロードマップを把握し続けることができます。ソフトウェアのアップグレードや置き換えには、科学者に数日または数週間の作業が必要な場合があります。ダウンタイムを避けるために、レシピはアプリケーションの状況変化に対応するように修正する必要があります。
科学者が実装したレシピは、収益のドルまたはユーロを最適化します。このシリーズの最初の講義でこの側面について説明しました。ただし、コストと利益のモデリング方法を決定することを科学者に期待するべきではありません。経済的な要因を反映するモデルを提案するべきですが、それが正しいかどうかは最終的には財務の役割です。多くのサプライチェーンの実践では、サービスレベルや予測の正確さなどの割合に焦点を当てています。しかし、これらの割合は会社の財務状態とほとんど相関がありません。したがって、科学者は定期的に財務と関わり、数値レシピで行われたモデリングの選択肢と仮定を問いかける必要があります。
財務モデリングの選択肢は一時的なものであり、企業の変化する戦略を反映しています。科学者は、将来の年に在庫に関連する最大の予測される運転資本額など、財務部門に関連するレシピにいくつかの計測器を作成することも期待されています。中規模または大規模な企業では、サプライチェーン科学者が行った作業の四半期ごとのレビューを財務の役員が行うことは合理的です。
レシピの妥当性に対する最大の脅威の1つは、会社の戦略的意図を誤って裏切ることです。多くのサプライチェーンの実践では、パフォーマンスの指標として使用される割合によって戦略を回避しています。販売と運用計画（S＆OP）を通じて予測を膨らませたり縮小したりすることは、戦略的意図を明確にすることの代替手段ではありません。科学者は会社の戦略を担当していませんが、戦略を理解していない場合、レシピは正しくありません。レシピを戦略と調整する必要があります。
科学者が戦略を理解しているかどうかを評価する最も直接的な方法は、彼らにそれをリーダーシップに再説明させることです。これにより、誤解がより簡単に見つかることができます。理論的には、この理解は科学者によってイニシアチブマニュアルに既に文書化されています。しかし、経験から、役員は詳細にオペレーションの文書をレビューする時間をほとんど持っていないことがわかっています。簡単な会話により、両者のプロセスが迅速化されます。
この会議は、科学者がサプライチェーンモデルや財務結果についてすべてを説明するためのものではありません。唯一の目的は、デジタルペンを持つ人物の適切な理解を確保することです。大企業でも、科学者がCEOや関連する役員と少なくとも年に1回会うことは合理的です。リーダーシップの意図により適合したレシピの利点は非常に大きく、しばしば過小評価されています。
サプライチェーンの改善は、継続的なデジタル化の一環です。これには会社自体の再編成が必要です。変更は急激ではないかもしれませんが、時代遅れの慣行を取り除くことは困難です。正しく実行されれば、サプライチェーンの科学者の生産性は従来のプランナーよりもはるかに高くなります。1人の科学者が数十億ドルまたはユーロ以上の在庫を管理することは珍しくありません。
サプライチェーンの人員を劇的に削減することも可能です。Lokadのクライアント企業の中には、過去に激しい競争圧力にさらされていた企業がこのアプローチを取り、それによる節約の一部によって生き残った例もあります。ただし、ほとんどのクライアントは、プランナーが自然に他のポジションに移るにつれて、人員をより徐々に削減することを選択しています。
残るプランナーは、顧客とサプライヤーに対して自分たちの努力を再調整します。彼らが収集するフィードバックは、サプライチェーンの科学者にとって非常に役立ちます。実際、科学者の仕事は本質的に内向きです。彼らは会社のデータ上で作業し、単に存在しないものを見ることは困難です。
長い間、多くのビジネスの声が顧客とサプライヤーとの強い結びつきを求めてきました。しかし、それは簡単に言うことはできません。特に、持続的な消火活動、顧客への安心、サプライヤーへの圧力によって努力が定期的に無力化される場合です。サプライチェーンの科学者は、両面で非常に必要な救済策を提供できます。
S&OP（販売と運用計画）は、共有の需要予測を通じて企業全体の調整を促進するための広く行われているプラクティスです。しかし、どんなに元々の意図があったとしても、私が目にしたS&OPプロセスは、無生産的な会議の連続として最もよく特徴付けられていました。ERPの導入とコンプライアンス以外に、S&OPほど魂を傷つける企業のプラクティスは思いつきません。ソビエト連邦は消えてしまったかもしれませんが、ゴスプランの精神はS&OPを通じて生き続けています。
S&OPの詳細な批判は、独自の講義を必要とします。しかし、簡潔さのために言えることは、サプライチェーンの科学者は、重要なすべての側面でS&OPに優れた代替手段です。S&OPとは異なり、サプライチェーンの科学者は現実の意思決定に基づいています。科学者が膨張した企業の官僚機構の一部になることを防ぐ唯一の要素は、彼らの性格や能力ではなく、実際の意思決定を通じてゲームに参加していることです。
プランナーや在庫管理者、生産管理者は、さまざまなビジネスレポートの大量消費者です。これらのレポートは、ビジネスインテリジェンスツールとして一般的に言及されるエンタープライズソフトウェア製品によって通常生成されます。典型的なサプライチェーンのプラクティスは、一連のレポートをスプレッドシートにエクスポートし、その情報を組み合わせるためのスプレッドシートの数式のコレクションを使用して、興味のある意思決定を半手動で生成することです。しかし、私たちが見てきたように、科学者のレシピはこのビジネスインテリジェンスとスプレッドシートの組み合わせを置き換えます。
さらに、ビジネスインテリジェンスもスプレッドシートも、レシピの実装をサポートするのに適していません。ビジネスインテリジェンスは表現力に欠けており、このクラスのツールでは関連する計算を表現することができません。スプレッドシートは保守性に欠け、時にはスケーラビリティにも欠けますが、主に保守性に欠けます。スプレッドシートの設計は、サプライチェーンの目的には非常に必要な設計上の正確さとはほとんど互換性がありません。
実際のところ、科学者によって実装されたレシピの計器化には、多数のビジネスレポートが含まれています。これらのレポートは、これまでビジネスインテリジェンスによって生成されていたものを置き換えます。この進化はビジネスインテリジェンスの終わりを意味するわけではありませんが、他の部門はこのクラスのツールを引き続き利用することができます。しかし、サプライチェーンに関しては、サプライチェーンの科学者の導入はビジネスインテリジェンス時代の終わりを告げるものです。
数百人、もしくは数千人のエンジニアをあらゆるソフトウェアの問題に投入できる数少ないテックジャイアントを除けば、通常の企業のデータサイエンスチームの結果は悲惨です。通常、これらのチームは実質的な成果を何も上げることがありません。ただし、データサイエンスは企業の実践としては、一連の企業の流行の最新のイテレーションに過ぎません。
1970年代には、オペレーションリサーチが大流行しました。1980年代には、ルールエンジンと知識エキスパートが人気でした。世紀の変わり目には、データマイニングとデータマイナーが求められました。2010年代以降、データサイエンスとデータサイエンティストが次のビッグなものと考えられています。これらの企業のトレンドはすべて同じパターンに従います。真のソフトウェアイノベーションが発生し、人々がそれに過度に熱狂し、新たな専門部署の設立を通じてこのイノベーションを会社に強制的に組み込むことを決定します。これは、既存の部署を変更または削除するよりも、組織に部門を追加する方がはるかに簡単だからです。
ただし、企業の実践としてのデータサイエンスは、行動にしっかりと根ざしていないため失敗します。これは、実世界の意思決定を生成する責任を負うために初日からコミットするサプライチェーンの科学者とIT部門との間の違いです。
エゴや封建制度を置いておけば、サプライチェーンの科学者は以前の現状よりもはるかに優れた取引です。典型的なIT部門は、数年間のバックログに埋もれており、さらなるリソースの追求は合理的な提案ではありません。なぜなら、それによって他の部門の期待が高まり、バックログがさらに増えるからです。
それに対して、サプライチェーンの科学者は期待の低下の道を切り開きます。科学者は、生データの抽出が可能であることだけを期待し、データの解析に関する戦いは彼らの責任です。彼らはこの点でIT部門から何も期待しません。サプライチェーンの科学者は、シャドウITの企業公認バージョンとして見なされるべきではありません。これは、サプライチェーン部門が自らのコアコンピタンスに責任を持ち、説明責任を持つことを目指しています。IT部門は低レベルのインフラストラクチャとトランザクションレイヤを管理し、サプライチェーンの意思決定レイヤは完全にサプライチェーン部門に委ねられるべきです。
IT部門は、真のIT中心のビジネスを除いて、意思決定者ではなくエンエーブラーでなければなりません。多くのIT部門は、自分たちのバックログを認識して、この新しい取引を受け入れています。ただし、自分たちの領域と認識されているものを守ろうとする本能が強すぎる場合、サプライチェーンの意思決定レイヤを手放すことを拒否する可能性があります。これらの状況は痛ましく、CEOの直接介入によってのみ解決することができます。
遠くから見れば、サプライチェーンの科学者の役割は、データサイエンティストのより専門的なバリエーションと見なすことができます。歴史的には、これがLokadがデータサイエンスの企業実践に関連する問題を解決しようとした方法でした。しかし、私たちは10年前にこれが不十分であることに気付きました。今日紹介されたすべての要素を徐々に明らかにするのに数年かかりました。
サプライチェーンの科学者は、会社のサプライチェーンに追加されるものではなく、日常のサプライチェンの意思決定の所有権に関する明確化です。このアプローチを最大限に活用するためには、サプライチェーン、少なくともその計画コンポーネントを再構築する必要があります。財務やオペレーションなどの隣接部門も、はるかに少ない程度でいくつかの変更を受け入れる必要があります。
企業がサプライチェーンの科学者のチームを育成することは、大きな責任ですが、適切に行われれば生産性は高くなります。実際には、各科学者は10人から100人のプランナーや予測者、在庫管理者を置き換えることになり、科学者の給与が高くても莫大な人件費の節約が得られます。サプライチェーンの科学者は、ITとの新しい取引を示し、ITをソリューションプロバイダーではなくエンエーブラーとして位置付け、多くのIT関連のボトルネックを解消します。
より一般的には、このアプローチはマーケティング、営業、財務など、他の非IT部門でも同様に反映されることができます。各部門には、それぞれ日常の決定を対処する必要があり、同様の自動化の恩恵を広範に受けることができます。ただし、サプライチェーンの科学者がまず第一にサプライチェーンの専門家であるように、マーケティングの科学者やマーケティングの数量化者もマーケティングの専門家であるべきです。科学者の視点は、21世紀初頭の機械と人間の知性の組み合わせを最大限に活用するための道を開きます。
ただし、サプライチェーンの科学者がまず第一にサプライチェーンの専門家であるように、マーケティングの科学者やマーケティングの数量化者もマーケティングの専門家であるべきです。科学者の視点は、21世紀初頭の機械と人間の知性の組み合わせを最大限に活用するための道を開きます。
次回の講義は5月10日、水曜日、同じ時間、パリ時間の午後3時に行われます。今日の講義は非技術的な内容でしたが、次回は主に技術的な内容になります。価格最適化のための技術を紹介します。一般的なサプライチェーンの教科書には通常、価格はサプライチェーンの要素として取り上げられていませんが、価格は供給と需要のバランスに大きく貢献します。また、価格はドメインによって大きく異なる傾向があります。抽象的な考え方で誤ったアプローチをすることが非常に簡単です。したがって、私たちは自動車のアフターマーケットに焦点を絞ります。これは、このシリーズの講義の第3章で紹介したサプライチェーンの「ペルソナ」の1つであるシュトゥットガルトと共に、先に提示された要素を再検討する機会となります。
そして、質問に進みます。
質問: データサイエンスの分野が出現し、高校で教えるべきだということについて、学界はほぼ10年かかりました。サプライチェーンの科学の視点を採用することで、サプライチェーンの学界でも同じようなことが起こっているのでしょうか？
まず、フランスの高校でデータサイエンスが教えられていることは知りません。高校ではコンピュータ関連のことをほとんど教えていないし、データサイエンスなんて尚更です。それを教える教授や教師をどこで見つけるのかさえよくわかりません。ただ、高校生にデジタルの能力を持たせたいという気持ちは理解できます。プログラミングに慣れることは非常に良いことだと思いますし、私自身の経験から言って、子供の成熟度によっては7歳や8歳からでもできます。小学校でもできますが、基本的なプログラミングの概念、変数、命令のリストなどについて話しているだけです。データサイエンスは、高校で教えるべきことをはるかに超えていると私には思えます。天才などがいる場合を除いて、それは私にとって明らかに大学レベルの人々のためのものです。学部生や大学院生のどちらかです。
実際に、データサイエンスを前面に押し出すために、学界は10年かかりましたが、一時停止しましょう。私はデータサイエンスを企業の実践として説明しましたが、それは学界がデータサイエンスを教える際に行っていることの鏡像バージョンです。したがって、問題について考える必要があります。そして、ここで、私は問題の一つは、実際には実践していないものを教えることが非常に困難であるということです。少なくとも大学レベルでは、それ以下ではなくてもそうです。私が見ているのは、データサイエンスを教えている人々が、Microsoft、Google、Facebook、OpenAIなどの重要な場所で実際にデータサイエンスを行っている人々ではないという問題が既にあるということです。
サプライチェーンにおいても、同様の問題があり、適切な経験を持つ人々にアクセスすることは非常に困難です。私たちは、Lokadが数週間以内にサプライチェーンの学位向けの教材を提供し始めることを希望しています。Lokadが提供するこれらの洞察を学生に教える価値があるかどうかを判断するために、教授が独自の判断を行う必要があります。
質問: Lokadのドメイン固有言語は他で使われていないのですか？Lokad以外では、新しい雇用先で二度と使わないであろうものを学ぶ意欲をどのように引き出しますか？
これはまさに私がデータサイエンティストについて問題を抱えていた点です。人々は文字通り「TensorFlowをやりたい、私はTensorFlowの人間だ」と応募していました。これは正しい態度ではありません。技術ツールのセットで自分のアイデンティティを混同すると、本質を見失います。課題は、サプライチェーンの問題を理解し、それらに定量的に対処して生産レベルの意思決定を生成することです。
この講義では、サプライチェーンの科学者がレシピを維持するために6ヶ月かかり、ゼロからレシピを設計するために2年かかると述べました。私たちの経験では、Envisionという私たちの独自のプログラミング言語に完全に習熟するのに3週間かかります。Envisionは全体的な課題に比べて小さな詳細ですが、重要なものです。ツールが貧弱な場合、偶発的な問題に直面します。ただし、現実的には、これは全体のパズルの小さな一部です。
Lokadで時間を費やす人々は、サプライチェーンの問題について非常に多くを学びます。プログラミング言語は他の言語で書き直すこともできますが、コードの行数が増えるかもしれません。特に若いエンジニアは、多くの技術が一時的であることに気付いていません。それらは長くは続かず、通常は他のものに置き換えられます。
終わりのない技術の連続を見てきました。候補者が「技術的な詳細に本当に興味がある」と言った場合、それはおそらく良い候補者ではありません。それが私がデータサイエンティストについて抱えていた問題でした-彼らは最新の最先端のものを求めていました。サプライチェーンは非常に複雑なシステムであり、間違いを犯すと何百万もの費用がかかることがあります。最新の未検証のパッケージではなく、生産レベルのツールが必要です。
最適な候補者は、サプライチェーンの専門家になるという真の興味を持っています。重要なのはサプライチェーンであり、プログラミング言語の詳細ではありません。
質問: 私はサプライチェーン、輸送、物流管理の学士号を取得しています。どのようにしてサプライチェーンの科学者になれますか？
まず、Lokadに応募することをお勧めします。常にポジションが空いています。しかし、もっと真剣に言うと、サプライチェーンの科学者になるための鍵は、サプライチェーンの意思決定を自動化しようとする企業の機会を持つことです。最も重要なのは、意思決定の所有権です。これに挑戦しようとする会社を見つけることができれば、あなたが科学者になるのを助ける大きな一歩となるでしょう。
製品のライフサイクル - Ep 144
質問: サプライチェーンの科学者の日常業務の40%がコーディングであるため、学部生に最初に学ぶことをお勧めするプログラミング言語は何ですか、特に管理学を学んでいる人に対しては？
私は、手軽にアクセスできるものをおすすめします。Pythonは良いスタートです。実際にいくつかのプログラミング言語を試してみることを提案します。サプライチェーンエンジニアに期待することは、ソフトウェアエンジニアに期待することとはまったく逆です。ソフトウェアエンジニアに対しては、一つの言語を選んで深く学び、ニュアンスを完全に理解することをデフォルトのアドバイスとしています。しかし、最終的にはジェネラリストになる人々に対しては、逆のことを言います。少しSQLを試してみたり、少しPythonを試してみたり、少しRを試してみたりしてください。Excelの構文に注意を払い、Rustのような言語を見てみるのも良いでしょう。ですので、手軽にアクセスできるものを選んでください。ちなみに、LokadではEnvisionを学生に無料で提供する予定ですので、お楽しみに。
質問: グラフデータベースはサプライチェーンの予測に重要な影響を与えると思いますか？
全くそうではありません。グラフデータベースは20年以上前から存在していますが、興味深いものの、PostgreSQLやMariaDBのような関係データベースほど強力ではありません。サプライチェーンの予測には、グラフのような演算子が必要なわけではありません。予測の競技では、トップ100の参加者の中にグラフデータベースを使用している人はいませんでした。ただし、グラフに適用されたディープラーニングによって行われることができることがあります。それについては、次回の価格に関する講義で説明します。
カスタマーデータサイエンスプロジェクトの目標定義にサプライチェーンの科学者が関与すべきかどうかという問題については、問題を理解する前にデータサイエンスに焦点を当てるという根本的な仮定に問題があると考えています。ただし、質問を言い換えると、サプライチェーン最適化の目標定義にサプライチェーンの科学者が関与すべきかということですか？はい、絶対に関与すべきです。科学者が本当に望んでいるものを明らかにすることは難しいですし、正しい目標を追求するためにステークホルダーとの緊密な協力が必要です。ですので、科学者はそのために参加すべきです。それは重要なことです。
ただし、これはデータサイエンスの取り組みではなく、データを適切な要素として使用できるサプライチェーンの取り組みです。私たちは本当にサプライチェーンの問題と目標から始める必要がありますし、現代のソフトウェアを最大限に活用したい場合には、これらの科学者が必要です。彼らは問題の理解をさらに磨くのに役立ちます。なぜなら、ソフトウェアで実現可能なことと、厳密に人間の知性の領域に残ることとの区別の線は、ある程度曖昧です。この区別の線を科学者がナビゲートする必要があります。
次回の講義では、5月10日にお会いしましょう。そこでは価格について話し合います。それでは、またお会いしましょう。
