00:00 イントロダクション
02:31 野生の失敗の根本原因
07:20 成果物: 数値レシピ 1/2
09:31 成果物: 数値レシピ 2/2
13:01 これまでのストーリー
14:57 今日のタスク完了
15:59 イニシアチブのタイムライン
21:48 スコープ: 適用領域 1/2
24:24 スコープ: 適用領域 2/2
27:12 スコープ: システム効果 1/2
29:21 スコープ: システム効果 2/2
32:12 役割: 1/2
37:31 役割: 2/2
41:50 データパイプライン - 方法
44:13 トランザクションシステムについて
49:13 データレイクについて
52:59 分析システムについて
57:56 データの健康状態: 低レベル
01:02:23 データの健康状態: 高レベル
01:06:24 データ検査官
01:08:53 結論
01:10:32 今後の講義と視聴者の質問
説明
サプライチェーンの予測最適化を成功させるには、ソフトウェアとハードウェアの問題が絡み合っています。残念ながら、これらの側面を分けることはできません。ソフトウェアとハードウェアの側面は深く絡み合っています。通常、この絡み合いは、会社の組織図で定義された作業の分割と正面衝突します。サプライチェーンイニシアチブが失敗すると、失敗の根本原因はプロジェクトの初期段階でのミスです。さらに、初期のミスはイニシアチブ全体を形作り、後から修正することがほとんど不可能になります。これらのミスを避けるための主な結論を発表します。
フルトランスクリプト
サプライチェーンの講義シリーズへようこそ。私はジョアネス・ヴェルモレルです。今日は、「量的サプライチェーンイニシアチブの始め方」を紹介します。データ解析に基づくサプライチェーンのイニシアチブの大部分は失敗しています。1990年以来、大規模なサプライチェーンを運営する多くの企業が、3〜5年ごとに主要な予測最適化イニシアチブを立ち上げていますが、ほとんど結果を出せていません。現在、サプライチェーンやデータサイエンスのチームのほとんどは、予測最適化の新しいラウンドを開始していますが、それが予測プロジェクトや在庫最適化プロジェクトとしてフレーム化されていることにさえ気づいていません。彼らの会社がすでに同じような試みを何度も失敗している可能性さえも。
さらなるラウンドに進むことは、今回は違うという信念に基づくことがありますが、チームの多くは以前に行われた多くの失敗した試みについてさえ知らないことがよくあります。この状況の証拠として、サプライチェーンの意思決定には依然としてMicrosoft Excelが最も使用されていることが挙げられますが、これらのイニシアチブはより良いツールでスプレッドシートを置き換えることを目指していました。しかし、現在でもスプレッドシートなしで運営できるサプライチェーンは非常に少ないです。
この講義の目的は、予測最適化を提供するサプライチェーンのイニシアチブが成功する可能性を高める方法を理解することです。私たちは、いくつかの重要な要素を見直します。これらの要素はシンプルですが、多くの組織にとっては直感に反するものです。逆に、このようなイニシアチブの失敗をほぼ保証する一連の反パターンも見直します。
今日は、サプライチェーンのイニシアチブの非常に初期の段階での戦術的な実行に焦点を当てて、「物事を成し遂げる」マインドセットで議論します。会社のための大きな戦略的な影響については議論しません。戦略は非常に重要ですが、それについては後の講義で議論します。
ほとんどのサプライチェーンのイニシアチブは失敗しますが、その問題はほとんど公に言及されません。学術界では、フレームワーク、アルゴリズム、モデルを含むさまざまなサプライチェーンのイノベーションを誇る数万の論文が毎年発表されています。頻繁に、これらの論文はそのイノベーションがどこかで実際に導入されたと主張しています。しかし、私自身の簡単な観察からは、そのようなイノベーションはどこにも見当たりません。同様に、ソフトウェアベンダーは過去30年間にわたってスプレッドシートの優れた代替品を約束してきましたが、私の簡単な観察では、スプレッドシートは依然として広く使用されています。
私たちは、サプライチェーンの講義シリーズの第2章で既に触れられたポイントを再訪しています。単純に言えば、人々は失敗を宣伝する動機がほとんどないため、宣伝しません。さらに、サプライチェーンを運営する企業は通常大規模であるため、従業員が次々と異なるポジションに移動することによる機関の記憶の自然な喪失によって問題はさらに複雑化します。そのため、学術界もベンダーも、このかなり陰鬱な状況を認めていません。
私は、戦術的な実行の観点から失敗の最も一般的な原因を短い調査から始めることを提案します。実際、これらの原因は通常、イニシアチブの最初の段階で見つかります。
失敗の最初の原因は、存在しない問題、重要でない問題、またはサプライチェーン自体についての誤解を反映した問題を解決しようとする試みです。予測の精度の最適化は、おそらくそのような間違った問題の典型です。予測誤差の割合を減らすことは、会社に直接的なリターンのユーロやドルをもたらすわけではありません。在庫の特定のサービスレベルを追求する場合も同様です。それに対してユーロやドルのリターンを示すことは非常に稀です。
失敗の2番目の根本原因は、適切でないソフトウェア技術とソフトウェア設計の使用です。たとえば、ERPベンダーは、ERPが構築されているため、トランザクションデータベースをデータ解析イニシアチブのサポートに使用しようとする傾向があります。逆に、データサイエンスチームは、クールなことをするためにその日の最新のオープンソースの機械学習ツールキットを使用しようとする傾向があります。残念ながら、適切でない技術の部分は通常、莫大な摩擦と多くの偶発的な複雑さを生み出します。
失敗の3番目の根本原因は、労働力と組織の不正確な分割です。プロセスの各段階で専門家を割り当てるという誤った試みで、企業はイニシアチブをあまりにも多くの人々に分割する傾向があります。たとえば、データの準備は、予測の責任を負っていない人々によって非常に頻繁に行われます。その結果、ゴミのような入力からゴミのような出力が生じます。最終的なサプライチェーンの意思決定の責任をわずかに薄めることは、失敗の原因となります。
この短いリストにルート原因としてリストアップしていない1つの項目は、データの問題です。データは、サプライチェーンのイニシアチブの失敗の原因として非常に頻繁に非難されますが、これは非常に都合の良いことです。なぜなら、データはその非難に正確に応答することはできないからです。ただし、データは通常、悪いデータとの戦いに苦しんでいるという意味では、通常は非難されません。大企業のサプライチェーンは数十年前にデジタル化されました。購入、輸送、変換、生産、販売されるすべてのアイテムには電子レコードがあります。これらの記録は完璧ではないかもしれませんが、通常は非常に正確です。データを適切に処理することに失敗した場合、本当に非難されるべきはトランザクションではなく、人々です。
定量的なイニシアチブが成功するためには、正しい戦いを戦わなければなりません。まず最初に何を提供しようとしているのでしょうか？定量的なサプライチェーンの主要な成果物の1つは、エンドゲームのサプライチェーンの意思決定を計算するための核となる数値レシピです。この側面は、最初の章「製品指向のサプライチェーンにおけるデリバリー」のLecture 1.3で既に議論されています。この成果物の2つの最も重要な特性を再考してみましょう。
まず、出力は意思決定でなければなりません。たとえば、特定のSKUに対して今日何個のユニットを再注文するかを決定することは意思決定です。一方、特定のSKUに対して今日何個のユニットが要求されるかを予測することは数値的なアーティファクトです。エンドリザルトとなる意思決定を生成するためには、多くの中間結果、つまり多くの数値的なアーティファクトが必要です。ただし、手段と目的を混同してはなりません。
この成果物の2番目の特性は、意思決定である出力が、純粋に自動化されたソフトウェアプロセスの結果として完全に自動化されている必要があるということです。数値レシピ自体、つまり核となる数値レシピ自体は、手動操作を必要としてはなりません。もちろん、数値レシピの設計自体は、非常に人間の科学の専門家に大きく依存する可能性があります。ただし、実行は直接的な人間の介入に依存してはなりません。
サプライチェーンのイニシアチブを資本主義的な取り組みにするためには、数値レシピが必要です。数値レシピはリターンを生み出す生産的な資産となります。レシピは維持する必要がありますが、これにはマイクロ意思決定レベルで人間を関与させるアプローチと比べて1〜2桁少ない人々が必要です。
ただし、多くのサプライチェーンのイニシアチブは、サプライチェーンの意思決定をイニシアチブの成果物として正しくフレーム化していないため、失敗することがあります。代わりに、これらのイニシアチブは数値アーティファクトの提供に焦点を当てています。数値アーティファクトは、通常、意思決定自体をサポートするための材料として使用されることを意図しています。サプライチェーンで最も一般的に遭遇するアーティファクトは、予測、安全在庫、EOQ、KPIです。これらの数値は興味深いかもしれませんが、実際には存在しません。これらの数値はサプライチェーンに直接的な具体的な対応物を持たず、サプライチェーンに対する任意のモデリングの視点を反映しています。
数値アーティファクトに焦点を当てることは、イニシアチブの失敗につながります。なぜなら、これらの数値には直接的な現実世界のフィードバックが欠けているからです。意思決定が間違っている場合、悪い結果は意思決定に遡ることができます。しかし、数値アーティファクトに関しては、状況ははるかに曖昧です。実際、責任はあちこちに分散しています。すべての意思決定に寄与する多くのアーティファクトが存在します。中間に人間の介入がある場合、問題はさらに深刻です。
このようなフィードバックの欠如は、数値アーティファクトにとって致命的です。現代のサプライチェーンは複雑です。安全在庫、経済的発注数量、KPIを計算するための任意の公式を選択してください。この公式があらゆる方法で間違っている可能性が非常に高いです。この公式の正確性の問題は数学的な問題ではありません。これはビジネスの問題です。つまり、「この計算は私のビジネスの戦略的意図を真に反映していますか？」という問いに答えることです。その答えは会社によって異なり、時間の経過とともに会社が進化することもあります。
数値アーティファクトには直接的な現実世界のフィードバックが欠けているため、ナイーブで単純でおそらく広く間違った初期実装から、ほぼ正しいバージョンの数式に近づくための反復が可能なメカニズムも欠けています。それにもかかわらず、数値アーティファクトは非常に魅力的です。なぜなら、解決策に近づいているように見えるからです。数値、数式、アルゴリズム、モデルがあります。さらに、作り物のベンチマークとこれらの数値を比較することも可能です。作り物のベンチマークに対して改善することは、進歩の幻想を与え、非常に心地よいものです。しかし、結局のところ、それは幻想であり、モデリングの視点の問題です。
企業はKPIを見るために人々に報酬を支払ったり、ベンチマークを行ったりすることで利益を上げるわけではありません。利益を上げるためには、一つの意思決定を別の意思決定に続けて行い、そしてできるだけ次の意思決定を改善することが重要です。
この講義はサプライチェーンの一連の講義の一部です。これらの講義をある程度独立して保つことを試みていますが、これらの講義を順番に視聴する方がより意味があるポイントに達しました。この講義は、企業のための予測的最適化のようなものを提供することを意図した量的なサプライチェーンのイニシアチブの第7章の最初の講義です。
最初の章では、私のサプライチェーンに関する考え方について述べました。2章では、多くのサプライチェーンの状況が敵対的な性質を持つため、単純な方法論は打ち負かされるということを踏まえて、サプライチェーンに不可欠な一連の方法論を紹介しました。3章では、問題に焦点を当てた一連のサプライチェーンの人物像を紹介しました。つまり、私たちが解決しようとしているのは何かということです。
4章では、サプライチェーンそのものではないが、現代のサプライチェーンの実践に不可欠なと考えられる一連の分野を紹介しました。5章と6章では、サプライチェーンの意思決定を推進するための数値レシピのスマートな要素を紹介しました。具体的には、予測的最適化（予測の一般的な視点）と意思決定（サプライチェーンの問題に適用される数理最適化）です。この第7章では、これらの要素を実際のサプライチェーンのイニシアチブに組み合わせる方法について説明します。
今日は、サプライチェーンのイニシアチブを実施するための正しい方法について見直します。これには、先ほど説明したようにイニシアチブを適切な成果物でフレーム化することだけでなく、適切なタイムライン、適切な範囲、適切な役割も含まれます。これらの要素は、今日の講義の第一部を表しています。
講義の第二部は、データパイプラインに捧げられます。これは、データ駆動型またはデータ依存型のイニシアチブの成功には欠かせない重要な要素です。データパイプラインはかなり技術的なトピックですが、ITとサプライチェーンの間での適切な役割分担と組織が必要です。特に、品質管理は主にサプライチェーンの手に委ねられ、データの健全性レポートやデータインスペクターの設計が行われることになります。
オンボーディングは、イニシアチブの最初のフェーズであり、コアな数値レシピが作成されます。このオンボーディングは、段階的な本番環境への展開で終了し、この展開中に、数値レシピ自体によって以前のプロセスが徐々に自動化されていきます。
企業における最初の量的サプライチェーンイニシアチブの適切なタイムラインを考える際には、企業の規模、複雑さ、サプライチェーンの意思決定の種類、全体的な文脈によると思われるかもしれません。これは一部当てはまることですが、Lokadが10年以上にわたり数十のイニシアチブを行った経験から、ほぼ必ず6ヶ月が適切なタイムラインであることがわかりました。驚くべきことに、この6ヶ月のタイムラインは技術やサプライチェーンの具体的な要素とはほとんど関係がありません。それはむしろ人々や組織自体、そしてサプライチェーンの実施方法として通常は非常に異なると認識される方法に対して、人々や組織が快適になるまでにかかる時間に関係があります。
最初の2ヶ月はデータパイプラインの設定に費やされます。数分後にこのポイントを再訪しますが、この2ヶ月の遅延は2つの要因によるものです。まず、データパイプラインを信頼性のあるものにするために、数週間かかる可能性のあるまれな問題を解消する必要があります。2つ目の要因は、データの意味を理解するためのものであり、つまり、サプライチェーンの観点からデータが何を意味するのかを理解する必要があります。
3番目と4番目の月は、数値レシピ自体の迅速な反復に費やされます。これらの反復は、実際の最終的な意思決定を生成することが通常唯一の方法であり、レシピの基礎に何か問題があるかどうか、またはレシピに組み込まれたすべての仮定に何か問題があるかどうかを評価するために必要です。これらの2ヶ月は、サプライチェーンの実践者が、これらのソフトウェアによって駆動される非常に数量的で財務的な視点に慣れるのにかかる時間でもあります。
最後の2ヶ月は、通常は迅速な反復の比較的激しい期間の後に、数値レシピの安定化に費やされます。この期間は、レシピがプロダクションのような環境で実行される機会でもありますが、まだプロダクションを駆動していません。このフェーズは、サプライチェーンチームがこの新興ソリューションに信頼を置くために重要です。
このタイムラインをさらに短縮することは望ましいかもしれませんが、実際には非常に困難です。データパイプラインの設定は、適切なITインフラが既に整っている場合にはある程度加速することができますが、データに慣れるにはサプライチェーンの観点からデータが何を意味するのかを理解するために時間がかかります。2番目のフェーズでは、数値レシピの反復が非常に迅速に収束する場合、サプライチェーンチームは通常、数値レシピの微妙なニュアンスを探求し始める可能性があり、これも遅延を引き延ばすことになります。最後に、最後の2ヶ月は、プロダクションで重要なサプライチェーンの意思決定を駆動するソフトウェアに対する信頼を築くために必要な期間です。
全体として、約6ヶ月かかりますが、さらに短縮することは望ましいですが、困難です。ただし、6ヶ月はすでにかなりの期間です。数値レシピがまだサプライチェーンの意思決定を駆動していないオンボーディング期間から6ヶ月以上かかると予想される場合、イニシアチブは既にリスクにさらされています。余分な遅延がデータの抽出やデータパイプラインの設定に関連している場合、それはITの問題です。余分な遅延がソリューションの設計や構成に関連している場合、おそらくサードパーティのベンダーによってもたらされた問題があるということです。最後に、安定化したプロダクションのような実行が2ヶ月経過しても行われない場合、通常はイニシアチブの管理に問題があると言えます。
組織に新規性、新しいプロセス、または新しい技術を導入しようとする際には、一般的な知恵に従って小規模に始め、それが機能することを確認し、早期の成功を基に徐々に拡大することが望ましいとされています。残念ながら、サプライチェーンは一般的な知恵には従いませんし、この視点はサプライチェーンのスコーピングに関して特定の変化を伴います。スコーピングに関しては、サプライチェーンイニシアチブに関して何が対象であり、何が対象外であるかを大きく定義する2つの主要な要因があります。
適用領域は、スコーピングに影響を与える最初の要因です。サプライチェーン全体は直接観察することはできず、エンタープライズソフトウェアのレンズを通じて間接的にのみ観察することができます。データはこれらのソフトウェアから取得されます。イニシアチブの複雑さは、これらのソフトウェアの数と多様性に大きく依存します。各アプリは独自のデータソースであり、特定のビジネスアプリからデータを抽出して分析することは、かなりの作業を伴います。より多くのアプリに対処する場合、複数のデータベース技術、一貫性のない用語、一貫性のない概念など、状況を複雑にする要素が大幅に増えます。
したがって、スコープを確立する際には、ビジネスアプリ自体とそのデータベース構造によって通常は対象となる範囲が定義されることを認識する必要があります。この文脈では、小規模に始めるということは、初期のデータ統合のフットプリントを可能な限り小さく保ちながら、サプライチェーンイニシアチブ全体の完全性を保つことを意味します。アプリの統合に関しては、広くなるよりも深く進む方が良いです。特定のアプリのテーブルからいくつかのレコードを取得するためのITシステムが整っている場合、通常はそのテーブルからすべてのレコードと同じアプリの別のテーブルからすべてのレコードを取得するのは簡単です。
スコープの一般的な誤りの1つは、サンプリングです。サンプリングは通常、製品カテゴリ、サイト、またはサプライヤの短いリストを選ぶことによって達成されます。サンプリングは善意のあるものですが、それはアプリケーションの範囲で定義された境界に従っていません。サンプリングを実装するためには、データ抽出中にフィルタを適用する必要があり、このプロセスによってサプライチェーンイニシアチブが危険にさらされる可能性がある一連の問題が生じます。
まず、企業ソフトウェアからのフィルタリングされたデータ抽出は、フィルタリングされていない抽出と比較して、ITチームにより多くの労力を要します。まずフィルタを設計する必要があり、フィルタリングプロセス自体もエラーのもとです。誤ったフィルタをデバッグすることは常に手間がかかります。これにより、イニシアチブが遅延し、それによって危険にさらされる可能性があります。
2つ目に、イニシアチブをデータサンプル上で実行させることは、ソフトウェアのパフォーマンスの問題を引き起こす可能性があります。イニシアチブが後に全範囲に拡大すると、スケーラビリティの問題や、コンピューティングコストを制御しながら大量のデータを処理できないという問題が非常に頻繁に発生します。データのサンプル上でイニシアチブを実行することで、スケーラビリティの問題は隠されますが、後の段階で復活します。
データサンプル上での操作は、統計をより困難にするだけでなく、簡単にする方法です。実際、より多くのデータにアクセスできることは、ほとんどすべての機械学習アルゴリズムの精度と安定性を向上させる最も簡単な方法です。データのサンプリングはこの洞察に反します。したがって、小さなデータサンプルを使用する場合、イニシアチブはサンプル上で観察される数値の不規則な振る舞いによって失敗する可能性があります。これらの振る舞いは、データセット全体が使用された場合には大幅に軽減されていたでしょう。
システム効果は、スコープに影響を与える2番目の要素です。サプライチェーンはシステムであり、そのすべての部分はある程度結合されています。システム、どのシステムでも、システムの一部を改善しようとする試みは、問題を修正するのではなく、問題を移動させる傾向があります。例えば、1つの配送センターと多くの店舗を持つ小売ネットワークの在庫割り当て問題を考えてみましょう。1つの店舗を初期のスコープとして選ぶと、在庫割り当て問題においてこの店舗が事前に在庫を確保することで、配送センターがこの店舗に対して非常に高品質のサービスを提供することは簡単です。これにより、配送センターがこの店舗に対して在庫切れになることはありません。ただし、この在庫の確保は、ネットワーク内の他の店舗のサービス品質を犠牲にすることになります。
したがって、サプライチェーンイニシアチブのスコープを考える際には、システム効果を考慮する必要があります。スコープは、スコープ外の要素を犠牲にすることなく、ローカル最適化を行うことを大幅に防ぐように設計する必要があります。このスコーピングの一部は難しいですが、すべてのスコープはある程度漏れてしまいます。たとえば、サプライチェーンのすべての部分は、最終的には会社レベルで利用可能な現金の同じ額を競い合います。どこかに割り当てられたすべてのドルは、他の目的には利用できないドルです。ただし、特定のスコープは他のスコープよりもはるかに簡単に操作できます。システム効果を軽減する傾向があるスコープを選ぶことが重要です。
サプライチェーンイニシアチブのスコープについて考える際に、システム効果の観点から考えることは、多くのサプライチェーンの実践者にとって奇妙に感じるかもしれません。スコープに関しては、ほとんどの企業は内部組織をスコーピングの演習に投影する傾向があります。したがって、スコープのために選ばれる境界は、会社内の分業の境界を模倣する傾向があります。このパターンは、コンウェイの法則として知られています。コミュニケーションシステムのために半世紀前にメルビン・コンウェイによって提案されたこの法則は、サプライチェーン管理を含む、より広範な適用性があることが後にわかりました。
現在のサプライチェーンを支配している境界とシロは、サプライチェーンの意思決定を推進するために存在する比較的手動のプロセスの結果である分業によって駆動されています。たとえば、企業がサプライと需要のプランナーが1,000個以上のSKUを管理できないと評価し、企業全体で50,000個のSKUを管理する必要がある場合、企業は50人のサプライと需要のプランナーが必要です。しかし、サプライチェーンの最適化を50組の手で分割することは、企業全体で多くの非効率を導入することが保証されています。
それに対して、これらの意思決定を自動化するイニシアチブは、陳腐化またはまもなく陳腐化する分業を反映する必要はありません。数値レシピは一度に50,000個のSKUを最適化し、多くのシロが互いに対立することから生じる非効率を排除することができます。したがって、これらの意思決定を大幅に自動化することを意図したイニシアチブが、会社内の多くの既存の境界と重なるのは自然なことです。会社、実際には会社の経営陣は、特にスコーピングのレベルで既存の組織の境界を模倣する衝動に抵抗する必要があります。なぜなら、それが後に続くものを決定する傾向があるからです。
サプライチェーンはハードウェア、ソフトウェア、人々の面で複雑です。残念ながら、数量的なサプライチェーンイニシアチブを開始することは、少なくとも最初はサプライチェーンの複雑さをさらに増加させます。長期的には、サプライチェーンの複雑さを実際に大幅に減少させることができますが、おそらく後の講義で詳しく説明します。さらに、イニシアチブに関与する人々が多ければ多いほど、イニシアチブ自体の複雑さも増します。この追加の複雑さがすぐに制御されない場合、イニシアチブは自身の複雑さの下で崩壊する可能性が高いです。
したがって、イニシアチブの役割、つまり誰が何をするかについて考える際には、イニシアチブを実現可能にする最小限の役割のセットについて考える必要があります。役割の数を最小限にすることで、イニシアチブの複雑さを最小限に抑え、その成功の可能性を大幅に向上させることができます。この視点は、一つのことだけをする極端な専門家を好む大企業にとって直感に反する傾向があります。大企業は、一つのことだけをする極端な専門家を好む傾向があります。しかし、サプライチェーンはシステムであり、すべてのシステムと同様に、エンドツーエンドの視点が重要です。
Lokadでこのようなイニシアチブを実施する経験に基づいて、通常、イニシアチブを実施するための最小限の分業を表す4つの役割を特定しました。サプライチェーンのエグゼクティブ、データオフィサー、サプライチェーンの科学者、サプライチェーンの実践者です。
サプライチェーンのエグゼクティブの役割は、イニシアチブが最初に実現できるようにサポートすることです。生産においてサプライチェーンの意思決定を駆動するための設計が優れている数値レシピを得ることは、利益性と生産性の両面で大きなブーストを意味します。ただし、それは非常に多くの変化を消化するために多くのエネルギーとトップマネジメントのサポートが必要です。
データオフィサーの役割は、データパイプラインを設定および維持することです。彼らの貢献の大部分は、イニシアチブの最初の2か月以内に行われることが期待されています。データパイプラインが正しく設計されている場合、データオフィサーにはその後ほとんど継続的な努力は必要ありません。データオフィサーは、通常、イニシアチブの後の段階にはほとんど関与しません。
サプライチェーンの科学者の役割は、コアとなる数値レシピを作成することです。この役割は、データオフィサーが提供する生のトランザクションデータから始まります。データオフィサーからのデータの準備は期待されておらず、データの抽出のみが求められます。サプライチェーンの科学者の役割は、生成されたサプライチェーンの意思決定を所有することで終わります。意思決定に責任を持つのはソフトウェアではなく、サプライチェーンの科学者です。生成された意思決定ごとに、科学者自身がなぜこの意思決定が適切であるかを正当化できる必要があります。
最後に、サプライチェーンの実践者の役割は、数値レシピによって生成された意思決定に対して挑戦し、サプライチェーンの科学者にフィードバックを提供することです。実践者は意思決定をすることはできません。この人物は通常、少なくとも一部の範囲において、スプレッドシートやシステムの助けを借りてこれらの意思決定を担当してきました。小規模な会社では、サプライチェーンのエグゼクティブとサプライチェーンの実践者の両方の役割を1人で果たすことが可能です。また、データが容易にアクセスできる場合は、データオフィサーの必要性を回避することも可能です。これは、データインフラストラクチャに関して非常に成熟している企業で起こる可能性があります。逆に、企業が非常に大規模な場合、各役割を果たす人物はわずかですが、わずかです。
コアとなる数値レシピの本番展開は、サプライチェーンの実践者の世界にかなりの影響を与えます。実際、この取り組みの目的の大部分は、サプライチェーンの実践者の以前の仕事を自動化することです。ただし、数値レシピが本番になったら、それらの実践者を解雇するのが最善の方法ではないということを意味しません。次の講義でこの特定の側面を再検討します。
組織化されているということは、効率的であるか、効果的であるかを意味するものではありません。意図が良くても、サプライチェーンの取り組みに摩擦を生じさせ、しばしば完全に失敗させる役割があります。現在では、このような取り組みを失敗させる最初の役割は、データサイエンティストの役割であり、特にデータサイエンスチームが関与している場合はさらにそうです。ところで、Lokadは10年前にこれを苦い経験で学びました。
データサイエンティストとサプライチェーンの科学者という名前の類似性にもかかわらず、これらの2つの役割は実際には非常に異なります。サプライチェーンの科学者は、まず第一に、実世界での製品レベルの意思決定に関心を持っています。もしセミトリビアルな数値レシピでこれが達成できるなら、メンテナンスは簡単です。サプライチェーンの科学者は、サプライチェーンの最も細かい詳細に対して完全な責任を負います。信頼性とレジリエンスは、洗練度よりも重要です。
それに対して、データサイエンティストは、数値レシピのスマートな部分、モデル、アルゴリズムに焦点を当てています。データサイエンティストは、一般的な意味で、機械学習と数理最適化の専門家として自己を認識しています。技術面では、データサイエンティストは最新の先端オープンソースの数値ツールキットを学ぶ意欲がありますが、会社を運営している30年前のERPについて学ぶことは通常はしないです。また、データサイエンティストはサプライチェーンの専門家ではなく、通常はなる意思もありません。データサイエンティストは合意されたメトリックに基づいて最良の結果を提供しようとします。科学者はサプライチェーンの非常に平凡な詳細に対処する意欲はありません。これらの要素は他の人々によって処理されることが期待されています。
データサイエンティストを関与させることは、サプライチェーンの取り組みにとって破滅を招くことです。なぜなら、データサイエンティストが関与すると、サプライチェーンが焦点ではなくなり、アルゴリズムとモデルが焦点になるからです。最新のモデルやアルゴリズムが、スマートで技術志向の人にとってどれだけ気を散らす力を持っているかを過小評価しないでください。
サプライチェーンの取り組みに摩擦を生じさせる2番目の役割は、ビジネスインテリジェンス（BI）チームです。BIチームが取り組みの一部である場合、彼らは妨害になる傾向がありますが、データサイエンスチームよりもはるかに少ない程度です。BIの問題は主に文化的なものです。BIはレポートを提供する役割であり、意思決定ではありません。BIチームは通常、会社の各部門からの要求に応じて無限のメトリックの壁を作成する意欲があります。これは定量的なサプライチェーンの取り組みには適切な態度ではありません。
また、ビジネスインテリジェンスは、キューブまたはOLAPキューブを中心としたデータ分析の非常に特定のクラスのソフトウェアであり、インメモリシステムをスライスしてダイスすることができます。この設計は、サプライチェーンの意思決定を推進するのには通常適していません。
イニシアチブをフレーム化したので、イニシアチブに必要なハイレベルのITアーキテクチャを見てみましょう。
画面上のスキーマは、数量ベースのサプライチェーンイニシアチブの典型的なデータパイプラインのセットアップを示しています。この講義では、低レイテンシの要件をサポートしないデータパイプラインについて説明しています。私たちは、フルサイクルを約1時間で完了できるようにしたいのですが、1秒ではありません。購買注文などのほとんどのサプライチェーンの意思決定には、低レイテンシのセットアップは必要ありません。エンドツーエンドの低レイテンシを実現するには、今日の講義の範囲を超えた異なる種類のアーキテクチャが必要です。
トランザクションシステムは、主要なデータソースであり、データパイプラインの出発点です。これらのシステムには、ERP、WMS、EDIなどが含まれます。これらのシステムは、購買、輸送、生産、販売などの商品の流れに関わります。これらのシステムには、ほとんどの数値レシピで必要とされるほぼすべてのデータが含まれています。実質的にどのような規模の会社でも、これらのシステムまたはそれらの前身が少なくとも20年以上の間存在しています。
これらのシステムにほぼすべての必要なデータが含まれているため、数値レシピを直接これらのシステムに実装することは魅力的に思えるかもしれません。実際には、なぜでしょうか？数値レシピをERPに直接組み込むことで、このデータパイプラインの設定の手間を省くことができます。残念ながら、これはトランザクションシステムの設計のために機能しません。
これらのトランザクションシステムは、不変のデータベースを中心に構築されています。このエンタープライズソフトウェアの設計手法は、過去40年間非常に安定しています。ランダムにどの会社を選んでも、本番環境で稼働しているすべてのビジネスアプリケーションがトランザクションデータベースの上に実装されている可能性が高いです。トランザクションデータベースは、アトミック性、整合性、分離性、耐久性という頭字語ACIDで知られる4つの主要な特性を提供します。これらの特性の詳細については深入りしませんが、これらの特性により、データベースは安全におよび同時に多くの小規模な読み取り操作と書き込み操作を実行するのに非常に適しています。読み取り操作と書き込み操作の量も、かなりバランスが取れていることが期待されています。
ただし、最も細かいレベルで非常に有用なACID特性を提供するデータベースを介してデータを提供する場合、データベースリソースのコストが、それほどACID特性に重点を置かないアーキテクチャと比較して100倍に膨らむことが一般的です。ACIDは素晴らしいですが、非常に高いコストがかかります。
さらに、データベース全体のかなりの部分を読み取ろうとすると、データベースはしばらくの間応答しなくなる可能性があります。多くの企業は、ビジネスシステム全体が遅く、これらのシステムが1秒以上フリーズするという問題に苦情を言っています。通常、このサービスの品質の低下は、一度に多くの行を読み取ろうとする重いSQLクエリに遡ることができます。
したがって、コアの数値レシピは、本番環境をサポートするトランザクションシステムと同じ環境で動作することは許されません。実際、数値レシピは実行されるたびにほとんどのデータにアクセスする必要があります。したがって、数値レシピは、トランザクションシステムのパフォーマンスをさらに低下させないために、厳密に独自のサブシステムに保持する必要があります。
ちなみに、データ集約型のプロセスをトランザクションシステム内で実行するのは非常に悪いアイデアであることは数十年前から知られていますが、それはトランザクションシステム（ERP、MRP、WMS）のほとんどのベンダーが統合された分析モジュール（例：在庫最適化モジュール）を販売していることを防ぎません。これらのモジュールを統合することは、品質のサービスの問題を引き起こし、期待以下の機能を提供します。これらのすべての問題は、この単一の設計上の問題に遡ることができます：トランザクションシステムと分析システムは厳密に分離される必要があります。
データレイクはシンプルです。トランザクションデータのミラーであり、非常に大きな読み取り操作に適したものです。実際、トランザクションシステムは多くの小さな読み取り操作に最適化されており、非常に大きな読み取り操作には最適化されていません。したがって、トランザクションシステムのサービス品質を保持するためには、トランザクションデータを別のシステム、つまりデータレイクに注意深く複製する必要があります。この複製は注意深く実装する必要があります。通常、データを非常に増分的な方法で読み取り、トランザクションシステムに圧力をかけることを避けることを意味します。
関連するトランザクションデータがデータレイクにミラーリングされると、データレイク自体がすべてのデータ要求を処理します。データレイクの追加の利点は、複数の分析システムを提供できることです。ここではサプライチェーンについて説明していますが、マーケティングが独自の分析を必要とする場合、非常に同じトランザクションデータが必要になります。財務、営業などについても同じことが言えます。したがって、会社のすべての部門が独自のデータ抽出メカニズムを実装する代わりに、それらの抽出を同じデータレイク、同じシステムに統合することは合理的です。
技術的なレベルでは、データレイクはリレーショナルデータベースとして実装することができます。通常、ビッグデータの抽出に最適化され、カラム形式のデータストレージを採用します。データレイクは、トランザクションシステムと比較して、細かい粒度のトランザクション特性を放棄します。目標は、できるだけ安価かつ信頼性の高い大量のデータを提供することです。それ以上でもそれ以下でもありません。
データレイクは、元のトランザクションデータをミラーリングする必要があります。つまり、データレイクでデータを準備しないことが重要です。残念ながら、データレイクの設定を担当するITチームは、他のチームのためにデータを少し準備し、簡単にすることに誘惑されることがあります。しかし、データを変更することは、後の段階で分析を損なう複雑さを導入します。さらに、厳格なミラーリングポリシーに従うことは、ITチームがデータレイクを設定し、後で維持するために必要な作業量を大幅に減らすことにつながります。
既にBIチームが存在する企業では、BIシステムをデータレイクとして使用することが誘惑されるかもしれません。しかし、私はそれを強く勧めず、BIセットアップをデータレイクとして使用しないようにします。実際、BIシステム（ビジネスインテリジェンスシステム）のデータは既に大幅に変換されています。BIデータを活用して自動化されたサプライチェーンの意思決定を行うことは、ゴミの入力、ゴミの出力の問題を引き起こすものです。データレイクは、ERPなどの主要なデータソースからのみフィードされる必要があります。BIシステムのような二次的なデータソースではありません。
分析システムは、コアの数値計算レシピを含んでいます。また、意思決定自体を計器化するために必要なすべてのレポートを提供するシステムでもあります。技術的なレベルでは、分析システムには機械学習アルゴリズムや数理最適化アルゴリズムなどの「スマートな部分」が含まれています。ただし、実際には、それらのスマートな部分は、学習と最適化に関わる部分よりも少なくとも10倍多くのコード行数を要するデータの準備とデータの計器化によって占められています。
分析システムはデータレイクから切り離される必要があります。なぜなら、これらの2つのシステムは技術的な観点で完全に対立しているからです。ソフトウェアとして、データレイクは非常にシンプルで、非常に安定しており、非常に信頼性が高いことが期待されています。一方、分析システムは洗練されており、常に進化しており、サプライチェーンのパフォーマンスに関して非常に高いパフォーマンスを発揮することが期待されています。データレイクがほぼ完璧な稼働時間を提供する必要があるのに対して、分析システムはほとんど常に稼働している必要はありません。たとえば、毎日の在庫補充の意思決定を考える場合、分析システムは1日に1回だけ実行され、稼働する必要があります。
分析システムは、誤った意思決定を生成してそれらが本番環境に流れ込むよりも、意思決定の生成に失敗する方が良いとされています。購買注文などのサプライチェーンの意思決定を数時間遅延させることは、誤った意思決定を行うよりもはるかに深刻ではないことが一般的です。分析システムの設計は、含まれるスマートな要素によって強く影響を受ける傾向があるため、一般的に分析システムの設計についてはあまり多く言及することはありません。ただし、少なくとも1つの重要な設計プロパティがエコシステムで強制される必要があります。このシステムはステートレスでなければなりません。
分析システムは、できるだけ内部状態を持たないようにする必要があります。言い換えれば、データレイクによって提示されたデータから始まり、生成された意図したサプライチェーンの意思決定とサポートするレポートで終わるように、エコシステム全体が構築される必要があります。しばしば、分析システム内には遅いコンポーネント（例：機械学習アルゴリズム）があるため、前回の実行からの情報を保持するために状態を導入することが誘惑されます。しかし、前回の計算結果に依存することは、すべてを毎回ゼロから再計算する代わりに行うことは危険です。
実際、分析システム内に状態を持つことは意思決定を危険にさらします。データの問題は必ず発生し、データレイクレベルで修正されますが、分析システムは修正済みの問題を反映した意思決定を返す可能性があります。たとえば、需要予測モデルが壊れた販売データセットでトレーニングされた場合、予測モデルはデータセットの新しい修正バージョンで再トレーニングされるまで壊れたままです。データレイクで既に修正されたデータの問題の影響を分析システムが受けないようにする唯一の方法は、すべてを毎回リフレッシュすることです。それがステートレスであることの本質です。
一般的なルールとして、分析システムの一部が毎日置き換えるには遅すぎると判断された場合、この部分はパフォーマンスの問題と見なされる必要があります。サプライチェーンはカオスであり、何かが起こる日が必ずやってきます-火災、ロックダウン、サイバー攻撃-これには即時の介入が必要です。企業はすべてのサプライチェーンの意思決定を1時間以内にリフレッシュできる必要があります。遅い機械学習トレーニングフェーズが行われている間に10時間も待ち続けることはありません。
分析システムが信頼性を持って運用されるためには、適切に計測する必要があります。これがデータヘルスレポートとデータインスペクタの役割です。ところで、これらの要素はすべてサプライチェーンの責任であり、ITの責任ではありません。データヘルスモニタリングは、データの準備そのものよりも前に行われる最初のデータ処理フェーズであり、分析システム内で行われます。データヘルスは数値レシピの計測の一部です。データヘルスレポートは、数値レシピを実行するかどうかを示します。また、データの問題の原因を特定し、問題の解決を迅速化するためにも使用されます。
データヘルスモニタリングは、Lokadでは行われている実践です。過去10年間で、この実践は企業ソフトウェアの世界では普遍的なゴミ入りゴミ出しの状況を回避するために非常に貴重であることが証明されています。実際、データの処理イニシアチブが失敗すると、しばしば悪いデータが原因とされます。しかし、最初にデータの品質を強制するためのほとんどのエンジニアリング努力はほとんど行われていないことに注意することが重要です。データの品質は空から降ってくるものではありません。エンジニアリングの努力が必要です。
これまでに紹介したデータパイプラインは非常に最小限です。データミラーリングはソフトウェアの品質に関してはできるだけシンプルなものです。しかし、この最小限の構成でも、多くの動作するパーツがあります。多くのテーブル、多くのシステム、多くの人々が存在します。したがって、バグはどこにでもあります。これは企業ソフトウェアであり、その逆は非常に驚くべきことでしょう。データヘルスモニタリングは、分析システムが周囲のカオスを生き残るのを助けるために存在しています。
データヘルスはデータクリーニングと混同してはいけません。データヘルスは、トランザクションシステムに存在するトランザクションデータの忠実な表現が分析システムに提供されていることを確認することに関するものです。データの修正を試みることはありません。データはそのまま分析されます。
Lokadでは、通常、低レベルのデータヘルスと高レベルのデータヘルスを区別しています。低レベルのデータヘルスは、データの構造やボリュームに関する異常など、データの明らかな問題（たとえば、合理的な日付や数値でないエントリ、または期待される対応関係がない孤立した識別子など）をまとめたダッシュボードです。これらの問題はすべて見ることができ、実際には簡単なものです。困難な問題は、データがまったく存在しないために見ることができない問題から始まります。たとえば、データの抽出に何か問題が発生し、昨日から抽出された売上データには予想される行数の半分しか含まれていない場合、それは実際には生産を危険にさらす可能性があります。不完全なデータは特に悪質であり、数値レシピの生成には通常影響を与えませんが、入力データが不完全であるため、それらの決定はゴミになります。
テクニカルには、Lokadではデータヘルスモニタリングを1つのダッシュボードにまとめ、このダッシュボードは通常、データパイプライン自体に関連する問題が低レベルのデータヘルスによってキャプチャされるため、ITチーム向けに設計されています。理想的には、ITチームは一目ですべてが正常であるかどうか、さらなる介入が必要かどうかを判断できるはずです。
高レベルのデータヘルスモニタリングでは、ビジネスの観点から見て間違っていると思われる要素など、ビジネスレベルの異常な要素を考慮します。高レベルのデータヘルスは、在庫レベルがマイナスであるか、異常に大きな最小注文数量であるなどの要素をカバーします。また、会社が損失で運営しているか、ばかげて高い利益率で運営しているために意味のない価格などもカバーします。高レベルのデータヘルスは、データを見て「これは正しくないはずだ、問題がある」と言うことができるサプライチェーンの実践者が問題として認識する要素を網羅しようとします。
低レベルのデータヘルスレポートとは異なり、高レベルのデータヘルスレポートは主にサプライチェーンチーム向けです。実際、最小注文数量の異常などの問題は、ビジネス環境にある程度精通している実践者にとってのみ問題として認識されるでしょう。このレポートの目的は、一目ですべてが正常であり、さらなる介入が必要ないことを伝えることです。
先に述べたように、分析システムはステートレスであるべきだと言いました。しかし、データヘルスはそのルールを証明する例外です。実際、多くの問題は、現在の指標を前日の指標と比較することで特定することができます。したがって、データヘルスモニタリングは通常、前日の状態で観測された主要な指標としていくつかの状態を保持し、データの現在の状態での外れ値を特定するために使用します。ただし、データヘルスは純粋なモニタリングの問題であるため、データレイクレベルで問題が修正され、データヘルスの状態に過去の問題のエコーがある場合でも、サプライチェーンの意思決定を生成するロジックは完全にステートレスです。状態は、計測の一部にのみ関係します。
低レベルと高レベルのデータヘルスモニタリングは、不正確な意思決定を提供するリスクと、意思決定をタイムリーに提供しないリスクとの間のトレードオフの問題です。大規模なサプライチェーンを見ると、データの100％が正確であることを期待することは合理的ではありません。不正確なトランザクションエントリは発生することがありますが、それらはまれです。したがって、数値レシピが動作するためには、問題のボリュームが十分に低いと見なされる必要があります。データの問題に対する過敏さとデータの問題に対する寛容さとの間のトレードオフは、サプライチェーンの経済的な構成に大きく依存します。
Lokadでは、データの破損のあらゆる可能性を追いかける代わりに、低レベルおよび高レベルのデータヘルスと、後で説明するデータインスペクターの実装を担当するサプライチェーンの科学者は、実際に損害を与え、実際に発生している問題に対してデータヘルスモニタリングを調整しようとします。
Lokadのジャーゴンでは、データインスペクターまたは単にインスペクターとは、対象物に関連するすべての関連データをまとめたレポートのことです。対象物は、サプライチェーンの観点からの第一級市民であることが期待されます - 製品、サプライヤ、クライアント、または倉庫のいずれかです。たとえば、製品のデータインスペクターを考える場合、会社が販売する製品ごとに、この製品に関連付けられたすべてのデータをインスペクターで1つの画面で表示できるはずです。製品のデータインスペクターでは、一般的なすべての製品ではなく、1つのバーコードまたはパート番号に関連付けられたすべてのデータを表示します。
一目で確認できる2つのダッシュボードとして期待される低レベルおよび高レベルのデータヘルスレポートとは異なり、インスペクターは設計および運用中に必ず発生する質問や懸念に対応するために実装されます。実際にサプライチェーンの意思決定を行うためには、複数のテーブルからのデータを統合することが頻繁にあります。データがあちこちに散らばっているため、意思決定が疑わしい場合、問題の原因を特定するのは通常困難です。分析システムが見るデータとトランザクションシステムに存在するデータとの間には不一致があるかもしれません。データの統計的なパターンを捉えるのに失敗する誤ったアルゴリズムがあるかもしれません。誤った認識があり、疑わしいとされる意思決定は実際には正しいかもしれません。いずれの場合でも、インスペクターは対象物にズームインする可能性を提供することを意図しています。
有用であるためには、インスペクターはサプライチェーンとアプリケーションの特異性を反映する必要があります。その結果、インスペクターの作成はほぼ必ずカスタムの作業です。ただし、作業が完了すると、インスペクターは分析システム自体の計器の1つを表します。
結論として、ほとんどの数量的なサプライチェーンの取り組みは、開始前に失敗することがほぼ確実ですが、そうする必要はありません。失敗に向かわせる問題を避けるためには、成果物、タイムライン、範囲、およびルールの慎重な選択が必要です。残念ながら、これらの選択肢はしばしば直感に反するものです。これは、Lokadがこれまでの14年間の運営を通じて苦労して学んだことです。
取り組みの最初は、データパイプラインの設定に費やす必要があります。信頼性の低いデータパイプラインは、データ駆動型の取り組みが失敗する最も確実な方法の1つです。ほとんどの企業、さらにはIT部門のほとんどは、継続的な消火活動を必要としない非常に信頼性の高いデータパイプラインの重要性を過小評価しています。データパイプラインの設定の大部分はIT部門の責任ですが、サプライチェーン自体が操作する分析システムの計器については、サプライチェーンチームが責任を持つ必要があります。ITにこれを期待しないでください。これはサプライチェーンチームの責任です。データヘルスレポートは、企業全体の視点を採用する一方、データインスペクターは詳細な診断をサポートします。
今日は、イニシアチブを開始する方法について説明しましたが、次回はそれを終了する方法、あるいはむしろ実現する方法について見ていきます。9月14日（水曜日）に行われる次の講義では、私たちは旅を進め、コアな数値レシピを作成し、それが生成する意思決定を徐々に本番環境に導くためにどのような実行が必要かを見ていきます。また、サプライチェーンの日常業務に対してこの新しい方法がどのような意味を持つのか、より詳しく見ていきます。
さて、質問を見てみましょう。
質問: 実装が正しく行われない期限はなぜちょうど6ヶ月なのですか？
問題は実際には6ヶ月という期限を持っていることではありません。問題は、通常、イニシアチブが最初から失敗するように設定されていることです。それが問題です。もし予測最適化のイニシアチブが2年で結果を提供するという視点から始まるのであれば、そのイニシアチブはいずれ解消し、本番環境に何も提供できないまま失敗することがほぼ確実です。私なら、3ヶ月でイニシアチブが成功することを望みます。しかし、私の経験では、このようなイニシアチブを本番環境に導くためには、6ヶ月が最小のタイムラインを表しています。余分な遅延はイニシアチブの失敗リスクを増加させます。このタイムラインをさらに短縮するのは非常に困難です。なぜなら、すべての技術的な問題を解決した後、残りの遅延はイニシアチブの進行に関わる人々が動き出すまでの時間を反映しているからです。
質問: 調達部門など、彼らの大部分の業務を置き換えるイニシアチブによって、サプライチェーンの実践者はフラストレーションを感じるかもしれません。意思決定の自動化との衝突に対して、どのように対処することをお勧めしますか？
これは非常に重要な質問であり、次の講義で取り上げられる予定です。今日は、現代のサプライチェーンでサプライチェーンの実践者が行っていることのほとんどは、あまり報われていないと考えています。ほとんどの企業では、人々は一連のSKUやパートナンバーを受け取り、それらを絶え間なくサイクルさせながら、必要なすべての意思決定を行います。つまり、彼らの仕事は基本的にはスプレッドシートを見て、週に一度または可能ならば一日に一度それをサイクルすることです。これは充実した仕事ではありません。
短い答えは、Lokadのアプローチは、作業のすべての単調な側面を自動化することで、サプライチェーンの本当の専門知識を持つ人々がサプライチェーンの基本を問いかけることができるようにするという問題に対処しています。これにより、クライアントやサプライヤーとのより多くの議論が可能になり、すべてをより効率的にすることができます。数値レシピを改善するための洞察を収集することです。数値レシピの実行は退屈ですし、スプレッドシートを毎日サイクルする必要があった古い時代を後悔する人はほとんどいません。
質問: サプライチェーンの実践者は、サプライチェーンサイエンティストが生成する意思決定に対抗するためにデータヘルスレポートを使用することを期待されていますか？
サプライチェーンの実践者は、データヘルスレポートではなく、データインスペクターを使用することが期待されています。データヘルスレポートは、分析システムの入り口のデータが数値レシピの実行に十分な状態かどうかという問いに答える、企業全体の評価のようなものです。データヘルスレポートの結果は、数値レシピの実行を承認するか、問題が修正が必要であるとして反対するかの2つの選択肢です。データインスペクターは、次の講義でさらに詳しく説明されるものであり、サプライチェーンの実践者が提案されたサプライチェーンの意思決定について洞察を得るための入り口です。
質問: 例えば、在庫ポリシーを毎日更新することは可能ですか？サプライチェーンシステムは毎日のポリシー変更に対応できないため、システムにノイズを与えるだけではないでしょうか？
この質問の最初の部分に対処するために、解析モデルを毎日更新することは確かに可能です。例えば、Lokadは2020年にヨーロッパでロックダウンが行われる中で運営しており、国々がわずか24時間前の通知で閉鎖や再開を行っていました。これは非常に混沌とした状況を作り出し、毎日の即時の見直しが必要でした。Lokadはこの極端な圧力の下で運営し、ヨーロッパ全体でほぼ14ヶ月間にわたって毎日始まったり終わったりするロックダウンを管理しました。
したがって、解析モデルを毎日更新することは可能ですが、必ずしも望ましいわけではありません。サプライチェーンシステムには多くの慣性があり、適切な数値レシピはほとんどの意思決定のラチェット効果を認識する必要があります。一度生産を注文し、原材料が消費されると、生産を元に戻すことはできません。新しい意思決定をする際には、既に多くの意思決定が行われていることを考慮する必要があります。ただし、サプライチェーンが大幅な変更を必要としていることに気付いた場合、この修正を意思決定を遅らせるためだけに遅らせる意味はありません。変更を実装する最適な時期は今です。
質問のノイズの側面に関しては、数値レシピの正しい設計にかかっています。データのわずかな変動が数値レシピの結果を大きく変化させる不安定な設計は多くあります。確率的な視点で予測を行うことで、モデルはサプライチェーンでの外れ値が発生した際にも安定性を保つように設計することができます。
質問: 非常に大きな企業のサプライチェーンでは、異なるソースシステムへの依存が問題となります。これらのソースシステムからすべてのデータを1つの統一されたシステムに統合することは非常に困難ではないでしょうか？
多くの企業にとって、すべてのデータを取得することは大きな課題であることに完全に同意します。しかし、まず最初になぜそれが課題となるのか考える必要があります。前述したように、現在の大企業が運営するビジネスアプリケーションの99%は、主流でよく設計されたトランザクションデータベースに依存しています。一部の古いCOBOLの実装が奇妙なバイナリストレージ上で実行されているかもしれませんが、これは稀なケースです。ほとんどのビジネスアプリケーション、1990年代に展開されたものでさえ、クリーンな本番用トランザクションデータベースをバックエンドで使用しています。
トランザクションバックエンドがあれば、なぜこのデータをデータレイクにコピーすることが困難である必要があるのでしょうか？ほとんどの場合、問題は企業がデータを単純にコピーしようとしないことです。データを準備し変換しようとし、プロセスを過度に複雑化しようとします。ほとんどの現代のデータベースセットアップには、トランザクションデータベースからセカンダリデータベースにすべての変更をレプリケートするための組み込みのデータミラーリング機能があります。これは市場で最も頻繁に使用される上位20のトランザクションシステムの組み込みプロパティです。
企業はデータの統合に苦労する傾向がありますが、それはあまりにも多くを試みるために自身の複雑さによって崩壊してしまうためです。データが統合された後、企業はしばしばデータの接続をIT、BI、またはデータサイエンスチームに任せるという誤った考えに陥ります。ここで言いたいのは、サプライチェーンはマーケティングや営業、財務と同様に、自身の数値レシピを担当すべきだということです。これは企業のためにこの仕事をする横断的なサポート部門ではなく、関連部門内で行うべきです。
今日のお時間、ご興味、そしてご質問に感謝いたします。夏休み後の9月にお会いしましょう。
