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年以降、大規模なサプライチェーンを運営するほとんどの企業は、三年から五年ごとに大規模な予測最適化施策を立ち上げていますが、その成果はほとんど見られません。現在、サプライチェーンやデータサイエンスの大多数のチームは、別の予測最適化ラウンドを開始しているものの（通常、これらは予測プロジェクトや在庫最適化プロジェクトとして位置付けられます）、自社が既に同様の試みを行い、半ダースもの失敗を経験していることに気付いていません。
再度試みるのは、今回は結果が違うという信念からである場合もありますが、実際には多くの失敗事例に気付いていないチームがほとんどです。この状況の逸話的な証拠として、Microsoft Excelが依然としてサプライチェーンの意思決定を推進するための第一のツールであることが挙げられます。本来、これらの施策はスプレッドシートに代わる優れたツールを導入するはずでしたが、今日に至るまでスプレッドシートなしで運営できるサプライチェーンは非常に少ないのが現状です。
本講義の目的は、あらゆる予測最適化を実現しようとするサプライチェーン施策に成功の可能性を与える方法を理解することにあります。いくつかの重要な要素（これらの要素はシンプルでありながら、多くの組織にとって直感に反するものとして現れることが多い）を検証します。逆に、そうした施策の失敗をほぼ確実にするアンチパターンについても検証します。
本日は、物事を着実に進めるマインドセットでサプライチェーン施策の開始時点における戦術的な実行に焦点を当てます。企業全体の壮大な戦略的影響については議論しません。戦略は非常に重要ですが、この件については後の講義で取り上げます。
ほとんどのサプライチェーンの取り組みは失敗しており、その問題はほとんど公に語られることがありません。学界は毎年何万もの論文を発表し、フレームワーク、アルゴリズム、モデルなどあらゆる種類のサプライチェーン革新を自慢しています。しばしば、論文の中ではその革新がどこかで実際に運用されていると主張されています。しかし、私自身がサプライチェーンの現場を何気なく観察すると、これらの革新は一切見受けられません。同様に、software vendorsは過去30年間、スプレッドシートに代わる優れたシステムを約束してきましたが、私の何気ない観察ではスプレッドシートが依然として普及しています。
このサプライチェーン講義シリーズの第2章でも触れた点に立ち返ります。簡単に言えば、人々は失敗を宣伝するインセンティブを全く持っていないため、何も宣伝しないのです。さらに、サプライチェーンを運営する企業は大企業であることが多く、社員が次々と異動する自然な組織記憶の喪失により、問題が一層深刻化します。だからこそ、学界もベンダーもこのどんよりとした状況を認めようとはしません。
ここでは、戦術レベルでの実行において失敗する最も頻繁な根本原因について、簡単な調査を行うことを提案します。実際、これらの根本原因は取り組みの初期段階で典型的に見られるものです。
失敗の第一の原因は、存在しない、または重要ではない、あるいはサプライチェーンそのものに対する誤解に基づく誤った問題を解決しようとする試みです。予測精度の最適化は、このような誤った問題の典型例と言えるでしょう。予測誤差の割合を減らすことは、企業にとって直接的にユーロやドルの追加収益に結びつくわけではありません。同様の状況は、企業が自社の在庫に対して特定のサービスレベルを追求するときにも見られ、実際に収益に結びつくことは非常に稀です。
失敗の第二の根本原因は、適合しないソフトウェア技術や設計の使用にあります。たとえば、ERPベンダーは、ERPの基盤となるトランザクショナルデータベースを利用してデータ解析の取り組みを支援しようとします。一方、データサイエンスチームは、その時々の最先端のオープンソース機械学習ツールキットを使用しようとする傾向があります。不幸なことに、適合しない技術は通常、膨大な摩擦と予期せぬ複雑性を生み出します。
失敗の第三の根本原因は、労働分担や組織の不適切な分割にあります。各段階に専門家を配置しようとする誤った試みの結果、企業は取り組みをあまりにも多くの人々に分散させがちです。たとえば、データ抽出パイプラインは、予測を担当していない人々によって行われることが非常に多く、その結果、「ゴミが入ればゴミが出る」状況が至る所に発生します。最終的なサプライチェーンの意思決定の責任が薄まることは、失敗のレシピとなります。
ここで短いリストに挙げなかった根本原因のひとつに、悪いデータがあります。サプライチェーンの取り組みの失敗についてデータが非難されることは非常に多いですが、これは都合がよすぎる話であり、データ自体がその非難に応じるわけではありません。しかし、データが問題なのではなく、少なくとも悪いデータに苦しむという意味での問題ではありません。大企業のサプライチェーンは何十年も前にデジタル化され、購入、輸送、変換、製造、販売されるあらゆるアイテムにelectronic recordsが存在します。これらの記録は完璧ではない場合もありますが、通常は非常に正確です。もしデータの取り扱いに失敗したとしても、非難されるべきは取引そのものではありません。
定量的な取り組みを成功させるためには、正しい課題に取り組む必要があります。そもそも、私たちは何を提供しようとしているのでしょうか？定量的なサプライチェーンの主要な成果物のひとつは、最終的なサプライチェーンの意思決定を算出するコアとなる数値的レシピです。この点は、「Product-Oriented Delivery for Supply Chain」という最初の章の講義 1.3 ですでに論じられました。では、この成果物の最も重要な二つの特性を再確認してみましょう。
まず、出力は意思決定でなければなりません。例えば、本日何ユニットをreorderするかを決定する際、特定のSKUに対して行う判断は意思決定です。一方、特定のSKUに対して本日要求されるユニット数を予測することは、単なる数値的な成果物に過ぎません。最終的な意思決定を生み出すためには、多くの中間成果物、すなわち数多くの数値的アーティファクトが必要となります。しかし、手段と目的を混同してはなりません。
この成果物の第二の特性は、出力である意思決定が、完全に自動化されたソフトウェアプロセスの結果として実現されなければならないことです。数値的レシピそのもの、すなわちコアとなる数値的レシピは、いかなる手作業も含んではいけません。当然、数値的レシピの設計自体は、科学の非常に優れた人間の専門家に大いに依存する可能性があります。しかし、実行段階では直接的な人間の介入に依存するべきではありません。
成果物として数値的レシピを持つことは、サプライチェーンの取り組みを資本主義的な事業とするために不可欠です。その数値的レシピはリターンを生み出す生産的資産となります。レシピは維持されなければなりませんが、これは微細な意思決定レベルで人間を関与させるアプローチと比べ、必要な人数が1桁または2桁分少なくて済むのです。
しかし、多くのサプライチェーンの取り組みは、取り組みの成果物としてサプライチェーンの意思決定を正しく位置付けられないために失敗します。代わりに、それらの取り組みは数値的アーティファクトの提供に重点を置いています。数値的アーティファクトは、最終的な問題解決に至るための要素、通常は意思決定自体を支えるための材料として意図されます。サプライチェーンで最も一般的に見られるアーティファクトは、予測、safety stocks、EOQsおよびKPIです。これらの数値は興味深いものの、実体はありません。サプライチェーンにおいて、これらの数値は即座に具体的な物理的対応物を持たず、サプライチェーンに対する恣意的なモデリングの視点を反映しているにすぎません。
数値的アーティファクトに注目すると、取り組みが失敗する原因になります。なぜなら、これらの数値は重要な要素である直接的な実世界からのフィードバックを欠いているからです。意思決定が誤っている場合、その悪影響はその意思決定にまで遡ります。しかし、数値的アーティファクトにおいては、責任が多数のアーティファクトに分散されるため、状況は非常に曖昧になります。特に、途中で人間の介入が入ると、その問題はさらに悪化します。
このフィードバックの欠如は、数値的アーティファクトにとって致命的です。現代のサプライチェーンは非常に複雑です。安全在庫、経済発注量、またはKPIを算出する任意の数式を選んでみても、その数式があらゆる面で誤っている可能性が圧倒的に高いのです。数式の正しさの問題は数学的な問題ではなく、ビジネス上の問題なのです。つまり、「この計算は本当に自分のビジネスに対する戦略的意図を反映しているのか？」という問いに答える問題です。その答えは企業ごとに、さらには企業が時とともに進化する中で年ごとにも変わっていきます。
数値的アーティファクトは直接的な実世界からのフィードバックを欠いているため、初歩的で単純かつ大いに誤った初期実装から、実運用に耐えうる概ね正しい数式への反復改善の仕組みを持っていません。それでも、数値的アーティファクトは、解決策に近づいているという錯覚を与えるため非常に魅力的です。合理的で科学的、さらには実行可能であるかのように錯覚させます。我々は数値、数式、アルゴリズム、モデルを持っています。ベンチマークを行い、それらの数値を同様に捏造された数値と比較することすら可能です。捏造されたベンチマークに対して改善を示すことは、進歩の錯覚を与え、非常に心強いものです。しかし、結局のところ、それはあくまで錯覚に過ぎず、モデリングの視点の問題です。
企業は、KPIを眺めたりベンチマークを行うために人件費を支払うことで利益を上げるのではありません。企業が利益を生み出すのは、一つの意思決定のあとに次の意思決定を下し、そのたびに次の意思決定をより良くしていくからです。
この講義は一連のサプライチェーン講義の一部です。できるだけ独立性を保とうとしていますが、これらの講義を順に視聴した方が意味がある段階に達しました。本講義は、第7章の最初の講義であり、第7章はサプライチェーンの取り組みの実行に捧げられています。ここでいうサプライチェーンの取り組みとは、企業向けの予測最適化のような定量的サプライチェーンの取り組みを意味します。
最初の章では、サプライチェーンを学問としても実践としても捉えた私の見解について述べました。第2章では、サプライチェーンに不可欠な一連の方法論を提示しました。なぜなら、素朴な方法論は多くのサプライチェーンの状況における敵対性によって打ち負かされるからです。第3章では、私たちが何を解決しようとしているのか、すなわち問題に純粋に焦点を当てた一連のサプライチェーンpersonaeを紹介しました。
第4章では、厳密にはサプライチェーンそのものではないものの、現代のサプライチェーン実践に不可欠であると考える一連の分野を提示しました。第5章と第6章では、サプライチェーンの意思決定を推進するために意図された数値的レシピの賢い部分、すなわち予測最適化（予測の一般化された視点）と意思決定（本質的にサプライチェーン問題に適用される数学的最適化）を紹介しました。本第7章では、これらの要素をどのように実際のサプライチェーンの取り組みに組み込んで、これらの手法や技術を実運用に移すかについて論じます。
本日は、サプライチェーンの取り組みを実施する際に正しいとされる実践方法を振り返ります。これには、先ほど議論した適切な成果物による取り組みの枠組みづくりだけでなく、適切なタイムライン、適切な範囲、そして適切な役割の設定も含まれます。これらの要素は、本日の講義の第一部を構成しています。
講義の第二部では、データ主導またはデータ依存の取り組みの成功に不可欠な要素であるデータパイプラインについて詳しく解説します。データパイプラインは技術的には非常に専門的なトピックですが、IT部門とサプライチェーン部門との間で適切な労働分担と組織体制が求められます。特に、品質管理は主にサプライチェーン側が担い、データヘルスレポートやデータインスペクターの設計を行うべきであることがわかります。
オンボーディングは取り組みの第一段階であり、主要な数値レシピ、すなわち意思決定を生み出すための中核となるレシピ（補助要素を伴うもの）が作成されるフェーズです。オンボーディングは段階的に本番環境へ展開され、この展開過程で初期のプロセスは数値レシピ自体によって徐々に自動化されていきます。
企業における初の定量的サプライチェーン取り組みに適切なタイムラインを検討する際、企業の規模や複雑性、サプライチェーンの意思決定の種類、そして全体の状況に依存すると考えられるかもしれません。限定的にはその通りですが、Lokadが10年以上にわたって数十件の取り組みから蓄積した経験では、ほぼ常に6か月が適切なタイムラインであることが示されています。驚くべきことに、この6か月というタイムラインは技術やサプライチェーンの細部とはほとんど関係がなく、むしろ人々や組織が従来とは大きく異なるサプライチェーン運営方法に慣れるまでの時間に大きく依存しています。
最初の2か月間は、データパイプラインの構築に充てられます。この点については数分後に再度触れますが、この2か月の遅延は2つの要因によるものです。まず第一に、データパイプラインを信頼性の高いものにし、数週間かかる可能性のあるまれな問題を排除する必要があります。第二に、供給チェーンの観点からデータの意味を理解する、いわゆるデータのセマンティクスを把握する必要があるのです。
3か月目と4か月目は、サプライチェーンの意思決定を支える数値レシピ自体の迅速な反復作業に充てられます。実際の最終的な意思決定を生成することが、根本的なレシピやその前提条件に問題があるかどうかを評価する唯一の方法であるため、こうした反復作業は必要です。この2か月は、サプライチェーンの実務者が、この非常に定量的かつ財務的視点に慣れるためにも通常必要な期間です。
最後の2か月間は、通常、激しい迅速な反復期間を経た後の数値レシピの安定化に充てられます。この期間は、レシピが本番環境に近いセットアップで動作する機会でもありますが、まだ実際に生産を担う段階ではありません。このフェーズは、サプライチェーンチームがこの新たなソリューションに信頼を寄せるために重要です。
このタイムラインをさらに短縮できれば望ましいものの、実際には非常に困難であることが判明しています。適切なITインフラがすでに整っていれば、データパイプラインの構築はある程度加速可能ですが、データの意味を供給チェーンの観点から理解するには時間がかかります。第二フェーズでは、数値レシピの反復作業が極めて迅速に収束した場合、サプライチェーンチームは数値レシピの細部に目を向け始め、結果として遅延が拡大する可能性があります。最後の2か月は、通常、季節性が展開し、ソフトウェアが生産における重要なサプライチェーン意思決定を担っていることへの信頼を得るのに必要な期間です。
全体として、約6か月を要し、さらに短縮できれば望ましいものの、それは困難です。しかし、6か月という期間自体はすでに相当な長さです。もし、初日からオンボーディング期間、つまり数値レシピがまだサプライチェーンの意思決定を担っていない期間が6か月以上かかると予想されるなら、その取り組みはすでに危機に瀕していることになります。追加の遅延がデータ抽出やデータパイプラインの構築に起因するなら、IT上の問題があるということです。もし、追加の遅延がソリューションの設計または構成に関係しており、場合によっては第三者ベンダーによってもたらされたものであれば、技術自体に問題があるということです。最後に、2か月間の安定した本番環境に類似した運用後に本番展開がなされない場合は、通常、その取り組みの運営に問題があると言えるでしょう。
新たな革新、プロセス、または技術を組織に導入する場合、一般的な知恵として、小規模で始め、機能することを確認し、初期の成功を基盤として徐々に拡大していくことが推奨されます。しかし、残念ながらサプライチェーンはこの一般的な知恵にあまり寛容ではなく、スコーピング（範囲設定）に関して特有のひねりがあります。スコーピングの観点では、サプライチェーンの取り組みにおいて何が適切なスコープであり何が適切でないかを大きく定義する2つの主要な推進要因が存在します。
アプリケーション環境は、スコーピングに影響を与える第一の要因です。サプライチェーン全体を直接観察することはできず、エンタープライズソフトウェアのレンズを通してのみ間接的に観察できます。データはこれらのソフトウェアから取得され、その複雑さは、これらのソフトウェアの数と多様性に大きく依存します。各アプリはそれ自体がデータソースであり、特定の業務アプリからのデータ抽出および分析は通常、大規模な作業となります。アプリが多ければ多いほど、複数のデータベース技術、不統一な用語、不一致の概念に対処しなければならず、状況は非常に複雑になります。
したがって、スコープを設定する際には、適切な境界は通常、業務アプリやそのデータベース構造によって定義されることを認識しなければなりません。この文脈では、初期のデータ統合のフットプリントをできるだけ小さく保ちつつも、サプライチェーン取り組み全体の整合性を維持することが「スモールスタート」として理解されるべきです。アプリ統合においては、広く手を広げるよりも、深く掘り下げる方が効果的です。一度、あるアプリのテーブルからいくつかのレコードを取得するためのITシステムが整えば、そのテーブルの全レコードおよび同じアプリ内の別テーブルの全レコードを取得することは通常容易になります。
一般的なスコーピングの誤りのひとつは、サンプリングに陥ることです。サンプリングは通常、限られた製品カテゴリ、サイト、またはサプライヤーのリストを選ぶことで行われます。善意から行われるサンプリングですが、アプリケーション環境で定義された境界に従っていないため、データ抽出時にフィルターを適用する必要があり、そのプロセスが一連の問題を引き起こし、サプライチェーン取り組みを危険にさらす可能性があります。
まず、エンタープライズソフトウェアからフィルターを掛けたデータ抽出は、フィルターを掛けない抽出に比べて、ITチームにより多くの労力を要求します。まずフィルターを設計する必要があり、そのプロセス自体がエラーを起こしやすいのです。不適切なフィルターのデバッグは非常に手間がかかり、ITチームとの多くのやり取りを必要とするため、取り組みが遅延し、結果として危険にさらされます。
第二に、取り組みのオンボーディングをデータサンプル上で実施させると、後に取り組みが全体スコープへ拡大した際、膨大なソフトウェアパフォーマンスの問題を引き起こすことになります。大量のデータを処理しながら計算コストを抑制する能力の不足、すなわちスケーラビリティの問題は、ソフトウェアにおける非常に一般的な欠陥です。取り組みをサンプル上で運用すると、スケーラビリティの問題は隠蔽されますが、後になって大きな問題として表面化します。
データサンプル上での運用は、統計解析を容易にするどころか、むしろ困難なものにします。実際、より多くのデータにアクセスできることは、ほぼすべての機械学習アルゴリズムの精度と安定性を向上させる最も簡単な方法と言えます。データのサンプリングはこの考えに反するものであり、小規模なデータサンプルを使用すると、サンプル上で見られる不規則な数値挙動により取り組みが失敗する可能性があります。全データセットが使用されていれば、これらの挙動は大いに緩和されたでしょう。
システム効果は、スコーピングに影響を与える第二の要因です。サプライチェーンはシステムであり、そのすべての要素はある程度連動しています。システム全体の一部分を改善しようとする試みは、問題を根本的に解決するのではなく、単に別の場所に問題をシフトしてしまう傾向があります。例えば、1つの配送センターと多数の店舗を有する小売ネットワークにおける在庫割り当ての問題を考えてみましょう。初期のスコープとして単一の店舗を選んだ場合、その店舗に対しては、あらかじめ在庫を予約することで配送センターから非常に高いサービス品質を提供することが容易に可能です。そうすることで、この店舗をサービスする間、配送センターが品切れになることは決してありません。しかし、こうした在庫予約は、ネットワーク内の他店舗のサービス品質を犠牲にして行われることになります。
したがって、サプライチェーン取り組みのスコープを検討する際には、システム効果を十分に考慮しなければなりません。スコープは、範囲外の要素を犠牲にして局所的な最適化を行わないように設計されるべきです。このスコーピングの課題は、すべてのスコープがある程度の漏れを伴うため、非常に困難です。例えば、サプライチェーンのすべての部分は最終的には企業全体で利用可能な同じ資金を巡って競合します。どこかに割り当てられた1ドルは、他の用途に使えなくなる1ドルです。それでもなお、あるスコープは他のものよりも操作しやすい傾向にあります。システム効果を増幅させるのではなく、むしろ緩和するスコープを選ぶことが重要です。
サプライチェーン取り組みのスコーピングをシステム効果の観点から考えることは、多くのサプライチェーン実務者にとって奇妙に感じられるかもしれません。スコーピングに関しては、ほとんどの企業が内部組織の構造をそのままスコーピング作業に投影してしまいがちです。結果として、スコープとして選択される境界は、企業内で既に存在する労働分担の境界を模倣する傾向にあります。この現象はコンウェイの法則として知られており、半世紀前にメルヴィン・コンウェイによって通信システムのために提唱され、その後、サプライチェーン管理にも非常に広範囲で適用可能であることが判明しています。
現代のサプライチェーンを支配する境界やサイロは、サプライチェーンの意思決定を推進するために存在する、かなり手作業によるプロセスに起因する労働分担から生じています。例えば、ある企業が需要と供給のプランナー1人では最大1,000 SKUしか管理できないと判断し、全体で50,000 SKUを管理する必要がある場合、その企業は50名のプランナーを必要とするでしょう。しかし、サプライチェーンの最適化を50人に分割して任せると、企業全体で多くの非効率性がもたらされるのは明らかです。
それに対して、これらの意思決定を自動化する取り組みは、時代遅れまたはすぐに時代遅れとなる労働分担の境界に従う必要がありません。数値レシピは、これら50,000 SKUを一度に最適化し、数十のサイロが互いに競合することによって生じる非効率性を排除することができます。したがって、これらの意思決定を大幅に自動化する取り組みが、企業内の既存の多数の境界と重なるのは自然なことです。企業、正確にはその経営陣は、特にスコーピングの段階において、既存の組織的境界を模倣する衝動に抵抗しなければなりません。これは、その後の展開の方向性を大きく左右するためです。
サプライチェーンは、ハードウェア、ソフトウェア、そして人に関して非常に複雑です。不運なことに、定量的サプライチェーン取り組みを開始することで、少なくとも初期段階ではサプライチェーン自体の複雑さがさらに増大してしまいます。長期的には、実際にサプライチェーンの複雑さを大幅に軽減できる可能性もありますが、その点についてはおそらく後の講義で触れるでしょう。さらに、取り組みに関わる人が増えれば増えるほど、取り組み自体の複雑性も高まります。この追加の複雑さがすぐに管理されなければ、その取り組みは自身の複雑さに押し潰される危険性が非常に高まります。
したがって、取り組みにおける役割、つまり誰が何を担うのかを考える際には、その取り組みを成立させるために可能な限り最小限の役割のセットを検討する必要があります。役割の数を最小限に抑えることで取り組みの複雑さを軽減し、その結果、成功の可能性を大いに高めることができます。この視点は、極めて細分化された労働分担で運営することを好む大企業にとっては、直感に反するかもしれません。大企業は、特定の一つのことだけを専門とする極端なスペシャリストを好む傾向があります。しかし、サプライチェーンはシステムであり、いかなるシステムにおいても重要なのは、エンドツーエンドの視点です。
Lokadがこれらの取り組みを実施する中で得た経験に基づき、通常、取り組みを実現するために必要な最小限の労働分担は、サプライチェーン・エグゼクティブ、データオフィサー、サプライチェーン・サイエンティスト、そしてサプライチェーン・プラクティショナーの4つの役割で構成されることが確認されました。
サプライチェーン・エグゼクティブの役割は、取り組みが実行されるための基盤を支援することにあります。適切に設計された数値レシピが本番環境でサプライチェーンの意思決定を担うことは、収益性と生産性の両面で大幅な向上をもたらします。しかし、それはまた非常に大きな変革を伴うため、大企業においては、上層部からの多大なエネルギーと支援が必要となります。
データオフィサーの役割は、データパイプラインの構築および維持管理にあります。彼らの主要な貢献は、取り組み開始から最初の2か月間に集中すると期待されます。データパイプラインが正しく設計されていれば、その後、データオフィサーによる継続的な作業はほとんど必要なくなります。通常、データオフィサーは取り組みの後半段階にはあまり関与しません。
The role of the supply chain scientist is to craft the core numerical recipe. This role starts from the raw transactional data as made available by the data officer. No data preparation is expected from the data officer, only data extraction. The supply chain scientist’s role ends with taking ownership of the generated supply chain decision. It is not a piece of software that is responsible for the decision; it is the supply chain scientist. For every generated decision, the scientist themselves must be able to justify why this decision is adequate.
Finally, the role of the supply chain practitioner is to challenge the decisions generated by the numerical recipe and provide feedback to the supply chain scientist. The practitioner has no hope of taking the decision. This person has typically been in charge of those decisions so far, at least for a subscope, and usually with the help of spreadsheets and systems in place. In a small company, it is possible to have one person fulfilling both the role of the supply chain executive and the supply chain practitioner. It is also possible to bypass the need for a data officer if the data is readily accessible. This might happen in companies that are very mature as far as their data infrastructure is concerned. On the contrary, if the company is very large, it is possible to have a few, but only a tiny few, people filling each role.
The successful rollout in production of the core numerical recipe has quite an impact on the world of the supply chain practitioner. Indeed, to a large extent, the point of the initiative is to automate away the previous job of the supply chain practitioner. However, this does not imply that the best course of action is to fire those practitioners once the numerical recipe is in production. We will be revisiting this specific aspect in the next lecture.
Being organized doesn’t mean being efficient or being effective. There are roles that, despite being well-intentioned, add friction to supply chain initiatives, frequently to the point of making them fail altogether. Nowadays, the first role that contributes the most to making such initiatives fail tends to be the role of the data scientist, and even more so when a whole data science team is involved. By the way, Lokad learned this the hard way about a decade ago.
Despite the name similarity between data scientists and supply chain scientists, the two roles are actually very different. The supply chain scientist cares first and foremost about delivering real-world, production-grade decisions. If this can be achieved with a semi-trivial numerical recipe, even better; maintenance will be a breeze. The supply chain scientist takes full responsibility for dealing with the most minute details of the supply chain. Reliability and レジリエンス to ambient chaos matter more than sophistication.
On the contrary, the data scientist focuses on the smart parts of the numerical recipe, the models, and the algorithms. The data scientist, in general terms, perceives themselves as an expert in machine learning and mathematical optimization. In terms of technologies, a data scientist is willing to learn the latest bleeding-edge open-source numerical toolkit, but this person is typically unwilling to learn about the three-decade-old ERP that happens to run the company. Also, the data scientist isn’t a supply chain expert, nor usually willing to become one. The data scientist attempts to deliver the best results according to agreed-upon metrics. The scientist has no ambition to deal with the very mundane details of the supply chain; those elements are expected to be handled by other people.
Involving data scientists spells doom for these initiatives because, as soon as data scientists are involved, the supply chain isn’t the focus anymore – algorithms and models are. Never underestimate the power of distraction that the latest model or algorithm represents for a smart, technologically-minded person.
The second role that tends to add friction to a supply chain initiative is the ビジネスインテリジェンス (BI) team. When the BI team is part of the initiative, they tend to be a hindrance rather than anything else, although to a much lesser extent than the data science team. The problem with BI is mostly cultural. BI delivers reports, not decisions. The BI team is typically willing to produce endless walls of metrics as requested by every single division of the company. This is not the right attitude for a quantitative supply chain initiative.
Also, business intelligence as a piece of software is a very specific class of data analytics geared around cubes or OLAP cubes that let you slice and dice most in-memory systems in enterprise systems. This design is usually quite unfit to drive supply chain decisions.
Now that we have framed the initiative, let’s have a look at the high-level IT architecture that the initiative requires.
The schema on the screen illustrates a typical data pipeline setup for a quantitative supply chain initiative. In this lecture, I am discussing a data pipeline that does not support low latency requirements. We want to be able to complete a full cycle in about one hour, not one second. Most supply chain decisions, like purchase orders, do not require a low latency setup. Achieving end-to-end low latency requires a different kind of architecture, which is beyond the scope of today’s lecture.
The transaction systems represent the primary data source and the starting point of the data pipeline. These systems include the ERP, WMS, and EDI. They deal with the flow of goods such as purchasing, transport, production, and selling. These systems contain almost all the data that the core numerical recipe requires. For practically any sizeable company, these systems or their predecessors have been in place for at least two decades.
As these systems contain almost all the data we need, it would be tempting to implement the numerical recipe directly into these systems. Indeed, why not? By putting the numerical recipe right into the ERP, we would remove the need to go through the effort of setting up this entire data pipeline. Unfortunately, this does not work due to the very design of those transactional systems.
These transaction systems are invariably built with a transactional database at their core. This approach for the design of enterprise software has been exceedingly stable for the last four decades. Pick any random company, and chances are that every single business app in production has been implemented on top of a transactional database. Transactional databases offer four key properties that are known under the acronym ACID, which stands for Atomicity, Consistency, Isolation, and Durability. I’m not going to delve into the fine print of those properties, but suffice to say that these properties make the database very suitable for performing safely and concurrently many small read operations and many small write operations. The respective amounts of read operations and write operations are also expected to be fairly balanced.
However, the price to pay for those very useful ACID properties at the most granular level is that the transactional database is also very inefficient when it comes to servicing big read operations. A read operation that covers a sizable portion of the entire database, as a rule of thumb, if the data is serviced through a database that focuses on a very granular delivery of those ACID properties, then you can expect the cost of the computing resources to be inflated by a factor of 100 compared to architectures that don’t focus as much on those ACID properties at such a granular level. ACID is nice, but it comes at a massive premium.
Moreover, when someone attempts to read a sizable portion of the entire database, the database is likely to become unresponsive for a while as it dedicates the bulk of its resources to servicing this one big request. Many companies complain that their entire business systems are sluggish and that those systems frequently freeze for one second or more. Usually, this poor quality of service can be traced back to heavy SQL queries that attempt to read too many lines at once.
Therefore, the core numerical recipe cannot be allowed to operate in the same environment as the transactional systems that support production. Indeed, numerical recipes will need to access most of the data whenever they are run. Thus, the numerical recipe must be kept strictly isolated in its own subsystem, if only to avoid degrading the performance of those transactional systems further.
By the way, while it has been known for decades that it is a terrible idea to have a data-intensive process operating within a transactional system, this does not prevent most vendors of transaction systems (ERP, MRP, WMS) from selling integrated analytical modules, for example, inventory optimization modules. Having those modules integrated inevitably leads to quality of service problems while delivering underwhelming capabilities. All of those problems can be traced back to this single design problem: the transaction system and the analytical system must be kept in strict isolation.
The data lake is simple. It is a mirror of the transactional data geared towards very large read operations. Indeed, we have seen that transaction systems are optimized for many small read operations, not very large ones. Thus, in order to preserve the quality of service of the transactional system, the correct design consists of carefully replicating the transactional data into another system, namely the data lake. This replication must be implemented with care, precisely to preserve the quality of service of the transactional system, which typically means reading the data in very incremental ways and avoiding putting pressure spikes on the transactional system.
Once the relevant transactional data is mirrored into the data lake, the data lake itself serves all the data requests. An additional benefit of the data lake is its ability to serve multiple analytical systems. While we are discussing supply chain here, if marketing wants their own analytics, they will need this very same transactional data, and the same could be said for finance, sales, etc. Thus, instead of having every single department in the company implementing their own data extraction mechanism, it makes sense to consolidate all those extractions into the same data lake, the same system.
At the technical level, a data lake can be implemented with a relational database, typically tuned for big data extraction, adopting a columnar data storage. Data lakes can also be implemented as a repository of flat files served over a distributed file system. Compared to a transactional system, a data lake gives up on the fine-grained transactional properties. The goal is to serve a large amount of data as cheaply and as reliably as possible—nothing more, nothing less.
The data lake must mirror the original transactional data, which means copying without modifying anything. It is important not to prepare the data in the data lake. Unfortunately, the IT team in charge of setting up the data lake can be tempted to make things easier and simpler for other teams and thus prepare the data a little bit. However, modifying the data invariably introduces complications that undermine analytics at a later stage. In addition, sticking to a strict mirroring policy vastly diminishes the amount of effort needed for the IT team to set up and later maintain the data lake.
In companies where there is already a BI team in place, it can be tempting to use the BI systems as a data lake. However, I strongly advise against doing so and never use a BI setup as a data lake. Indeed, the data in BI systems (business intelligence systems) is invariably heavily transformed already. Leveraging the BI data to drive automated supply chain decisions is a recipe for garbage in, garbage out problems. The data lake must only be fed from primary data sources like ERP, not from secondary data sources like the BI system.
The analytical system is the one that contains the core numerical recipe. It is also the system that provides all the reports needed to instrument the decisions themselves. At the technical level, the analytical system contains the “smart bits,” like the machine learning algorithms and mathematical optimization algorithms. Although in practice, those smart bits are not dominating the codebase of the analytical systems. Usually, data preparation and data instrumentation take at least ten times as many lines of code as the parts dealing with learning and optimization.
The analytical system must be decoupled from the data lake because those two systems are completely at odds in terms of technological perspectives. As a piece of software, the data lake is expected to be very simple, very stable, and extremely reliable. On the contrary, the analytical system is expected to be sophisticated, under constant evolution, and extremely performant in terms of サプライチェーン-パフォーマンス-テスト. Unlike the data lake, which must deliver near-perfect uptime, the analytical system does not even have to be up most of the time. For example, if we are considering daily inventory replenishment decisions, then the analytical system only has to run and be up once per day.
As a rule of thumb, it’s better to have the analytical system fail at producing decisions rather than generating incorrect decisions and letting them flow into production. Delaying supply chain decisions by a few hours, like purchase orders, is typically much less dire than taking incorrect decisions. As the design of the analytical system tends to be heavily influenced by the smart bits it contains, there is not necessarily much to be said in general about the design of the analytical system. However, there is at least one key design property that must be enforced for the ecosystem: this system must be stateless.
The analytical system must avoid having an internal state to the greatest extent possible. In other words, the entire ecosystem must start with the data as presented by the data lake and end with the generated intended supply chain decisions, along with supporting reports. What often happens is that whenever there is a component inside the analytical system that is too slow, like a machine learning algorithm, it is tempting to introduce a state, that is, to persist some information from the previous execution to speed up the next execution. However, doing so, relying on previously computed results as opposed to recomputing everything from scratch every single time, is dangerous.
実際、解析システム内に状態を持つことは、意思決定を危険にさらします。データの問題は避けられずデータレイクの段階で修正されるとしても、解析システムはすでに修正済みの問題を反映している意思決定を返す可能性があります。たとえば、需要予測モデルが破損した販売データセットで学習された場合、その予測モデルは修正済みの新たなデータセットで再学習されるまで破損したままです。解析システムがデータレイクで既に修正されたデータ問題の反響を受けない唯一の方法は、その都度すべてをリフレッシュすることです。これがステートレスであるという本質です。
一般的な経験則として、解析システムの一部が日々置き換え可能なほど高速でなければ、その部分はパフォーマンス問題に苦しんでいると見なさなければなりません。サプライチェーンは混沌としており、火災、封鎖、サイバー攻撃といった何かが起こり、即時の介入が必要となる日が必ず来ます。企業は1時間以内にすべてのサプライチェーンの意思決定をリフレッシュできなければなりません。遅い機械学習のトレーニング段階が進行する間に10時間も待たされてはなりません。
信頼性ある運用を行うためには、解析システムは適切に計器化（インストゥルメンテーション）されなければなりません。それがデータ健康レポートやデータインスペクターの役割です。ちなみに、これらの要素はすべてサプライチェーンの責任であり、ITの責任ではありません。データ健康監視は、実際のデータ準備よりも前に行われる最初のデータ処理段階を表しており、解析システム内で行われます。データ健康は数値レシピの計器化の一部です。データ健康レポートは、数値レシピをそもそも実行して良いかどうかを示し、このレポートは、もしあれば問題の原因を特定して問題解決を迅速化します。
データ健康監視はLokadで実践されている手法です。過去10年間、この手法はエンタープライズソフトウェアの世界に遍在する「ゴミ入力、ゴミ出力」を避けるために非常に有用であることが証明されました。実際、データ処理の取り組みが失敗すると、不良なデータが原因とされることがよくあります。しかし、初めからデータ品質を強制するためのエンジニアリング努力はほとんど行われていないことに注意する必要があります。データ品質は空から降ってくるものではなく、エンジニアリングの努力が必要なのです。
これまでに提示されたデータパイプラインは非常にミニマリスティックです。データミラーリングは可能な限りシンプルであり、これはソフトウェア品質の観点からは良いことです。しかし、このミニマリズムにもかかわらず、多くのテーブル、多くのシステム、多くの人々といった多くの可動部分が存在します。そのため、あちこちにバグが潜んでいます。これがエンタープライズソフトウェアであり、そうでないとしたら非常に驚くべきことです。データ健康監視は、このような環境の混沌の中で解析システムが生き残るために設置されています。
データ健康はデータクリーニングと混同すべきではありません。データ健康は、解析システムに提供されるデータが、トランザクションシステムに存在する取引データを忠実に再現しているかを確認することに関するものであり、データを修正しようとはしません。そのままのデータが分析されるのです。
Lokadでは、通常、低レベルのデータ健康と高レベルのデータ健康を区別します。低レベルのデータ健康は、すべての構造的および体積的な異常を統合するダッシュボードであり、たとえば、妥当な日付や数字さえ成立しないエントリや、期待される対応関係が欠如している孤立した識別子などといった明らかな問題を集約します。これらの問題はすべて見えるもので、実際には容易な問題です。困難な問題は、そもそもデータが存在しないために見えない問題から始まります。例えば、データ抽出に問題があり、昨日抽出された販売データが予定行数の半分しか含んでいなければ、生産に深刻な危険を及ぼすでしょう。不完全なデータは特に厄介で、通常、数値レシピが意思決定を生成するのを妨げることはありませんが、入力データが不完全なため、その意思決定はゴミとなります。
技術的には、Lokadではデータ健康監視を1つのダッシュボードにまとめるようにしており、このダッシュボードは低レベルのデータ健康で検出される問題のほとんどがデータパイプライン自体に関連するため、主にITチーム向けに設計されています。理想的には、ITチームは一目で全てが正常であり、追加の介入が不要であるかどうかを判断できるはずです。
高レベルのデータ健康監視は、ビジネスの視点から見ておかしいと感じるすべてのビジネスレベルの異常を考慮します。高レベルのデータ健康は、負の在庫レベルや異常に大きな最小発注数量などの要素を含み、会社が損失を被るか途方もない高いマージンで運営されるために意味を成さない価格なども対象とします。高レベルのデータ健康は、サプライチェーン担当者がデータを見たときに「これはあり得ない、問題がある」と感じるすべての要素を網羅しようと試みます。
低レベルのデータ健康レポートと異なり、高レベルのデータ健康レポートは主にサプライチェーンチーム向けに考案されています。実際、異常な最小発注数量といった問題は、ビジネス環境にある程度精通している担当者にしか問題として認識されません。このレポートの目的は、一目で全体が正常であり、追加の介入が不要であることを示すことにあります。
以前、解析システムはステートレスであるべきだと言いました。しかし、実際にはデータ健康がその例外であることが判明しました。現状の指標と前日までに収集された同じ指標を比較することで多くの問題が識別できるのです。したがって、データ健康監視は通常、前日までに観測された主要な指標という形で何らかの状態を保持し、現状のデータにおける外れ値を識別できるようにします。しかし、データ健康は純粋に監視の問題であるため、もしデータレイクの段階で問題が修正され、その結果データ健康の状態に過去の問題の反響が見られたとしても、最悪の場合はそのレポートから一連の誤警報が発せられるだけです。サプライチェーンの意思決定を生成するロジックは完全にステートレスであり、状態は計器化の一部にのみ関係します。
低レベルおよび高レベルのデータ健康監視は、誤った意思決定を下すリスクと、意思決定をタイムリーに下せないリスクとの間のトレードオフの問題です。大規模なサプライチェーンを考えると、データの100％が正確であるとは期待できません―誤った取引エントリーは稀ではあるものの発生します。したがって、数値レシピが機能するためには、問題の発生量が十分に低いと見なされなければなりません。データの不具合に過敏になるか、またはデータ問題に対して寛容になりすぎるかというこれら2つのリスクのトレードオフは、サプライチェーンの経済構造に大きく依存します。
Lokadでは、これらのレポートをクライアントごとに作成し、微調整しています。あり得るすべてのデータ破損事例を追いかけるのではなく、これから説明する低レベルおよび高レベルのデータ健康やデータインスペクターの実装を担当するサプライチェーン科学者は、関心のあるサプライチェーンに実際に損害を与えている、または実際に発生している問題に敏感になるようにデータ健康監視の調整を試みます。
Lokadの業界用語でいうデータインスペクター（または単にインスペクター）とは、対象物に関連するすべてのデータを統合したレポートのことです。対象物は、製品、サプライヤー、クライアント、または倉庫など、サプライチェーンの観点から見て主要な存在であることが期待されます。たとえば、製品のデータインスペクターを検討する場合、企業が販売する任意の製品について、その製品に付随するすべてのデータを1つの画面で確認できなければなりません。製品のデータインスペクターでは、実質的に製品の数だけビューが存在します。なぜなら「すべてのデータを見る」というとき、すべての製品全体ではなく、1つのバーコードまたは部品番号に付随するすべてのデータを見ることを意味するからです。
一目で確認できる2つのダッシュボードとして想定される低レベルおよび高レベルのデータ健康レポートとは異なり、インスペクターはコアとなる数値レシピの設計および運用中に必然的に生じる疑問や懸念に対処するために実装されています。実際、サプライチェーンの意思決定を下すためには、複数の取引システムにまたがる十数のテーブルからデータを統合することは珍しくありません。データがあちこちに散らばっているため、意思決定が疑わしく見える場合、その問題の原因を特定するのは通常困難です。解析システムで見られるデータと取引システムに存在するデータとの間に乖離がある場合もあります。不具合のあるアルゴリズムが、データ中の統計的パターンを正しく捉えられていない可能性もあります。誤った認識があり、疑わしいと判断された意思決定が実際には正しい場合もあります。いずれの場合も、インスペクターは対象物を拡大して詳細を見る機能を提供することが目的です。
有用であるためには、インスペクターはサプライチェーンとアプリケーション環境の双方の特性を反映していなければなりません。その結果、インスペクターの作成はほぼ必ずオーダーメイドの作業となります。しかし、作業が完了すれば、インスペクターは解析システム自体の計器化の柱の1つとなります。
結論として、ほとんどの定量的サプライチェーンの取り組みは、開始前から失敗する運命にあるように見えますが、必ずしもそうである必要はありません。そのような取り組みを失敗に導く問題を避けるためには、成果物、タイムライン、範囲、ルールの慎重な選択が必要です。残念ながら、Lokadがこれまでの14年間の運用で痛感したように、これらの選択はしばしば直感に反するものとなります。
取り組みの最初の段階は、データパイプラインの構築に専念する必要があります。信頼性の低いデータパイプラインは、データ駆動型の取り組みが失敗することを確実にする最も確実な方法の一つです。ほとんどの企業、さらにはほとんどのIT部門でさえ、継続的な火消し作業を必要としない高信頼性のデータパイプラインの重要性を過小評価しています。データパイプラインの構築の大部分はIT部門に委ねられますが、運用する解析システムの計器化はサプライチェーン自身の責任です。これをITに任せてはいけません。これはサプライチェーンチームが担うべき事項です。私たちは、企業全体の視点を採用するデータ健康レポートと、詳細な診断をサポートするデータインスペクターという、2種類の異なる計器化を見てきました。
今日は取り組みの開始方法について議論しましたが、次回はその終了方法、いや実現に向けた方法について見ていきます。次回の講義は9月14日水曜日に行われ、そこで私たちは旅を進め、コアとなる数値レシピの作成と、それが生成する意思決定を徐々に本番環境に移行するために必要な実行段階を確認します。また、この新たなサプライチェーンのアプローチが、サプライチェーン担当者の日々の業務に何を意味するのかについても詳しく見ていきます。
さて、質問を見ていきましょう。
Question: Why is it exactly six months as a time limit after which an implementation is not done correctly?
私が言いたいのは、タイムリミットが6ヶ月であること自体が問題ではなく、通常、取り組みは最初から失敗するように設定されているという点です。もし予測最適化の取り組みが、結果が2年後に提供されるという視点で開始されれば、その取り組みはいつか解散し、本番環境で何も提供できなくなることがほぼ保証されます。可能であれば、私はその取り組みが3ヶ月で成功することを望みます。しかし、私の経験では、6ヶ月がそのような取り組みを本番環境に導くための最小のタイムラインを示しています。さらに遅れると、取り組みが失敗するリスクが高まります。一度すべての技術的問題が解決されると、残る遅延は、関係者が取り組みに慣れるまでの時間を反映するため、これ以上短縮するのは非常に難しいのです。
Question: Supply chain practitioners may get frustrated with an initiative that replaces the majority of their workload, such as the purchasing department, in conflict with decision automation. How would you advise handling this?
これは非常に重要な質問であり、次回の講義で取り上げる予定です。本日は、現代のサプライチェーンにおけるサプライチェーン担当者の多くの業務が、それほどやりがいのあるものではないと考えているということをお伝えしたいと思います。ほとんどの企業では、担当者はSKUや部品番号のセットを受け取り、それらを終始循環させながら必要な意思決定を行います。つまり、彼らの仕事は本質的にスプレッドシートを見て、週に一度、あるいは日一回、その内容を確認するという作業に過ぎません。これは決して充実感のある仕事ではありません。
簡潔に言えば、Lokad のアプローチは業務の煩雑な部分を自動化することで問題に対処し、サプライチェーンの真の専門知識を持つ人々がその根本を問い直すことを可能にします。これにより、クライアントやサプライヤーとより多く議論し、全体の効率を高めることが可能となります。必要な洞察を収集して数値レシピを改善することに他なりません。数値レシピの実行は面倒で、毎日スプレッドシートをあちこち確認していた過去を懐かしむ人はほとんどいないでしょう。
質問: サプライチェーンの実務担当者は、サプライチェーン科学者が生成する決定に異議を唱えるために、データヘルスレポートではなく、データインスペクターと連携して作業することが期待されるのでしょうか？
サプライチェーンの実務担当者は、データヘルスレポートではなくデータインスペクターと連携して作業することが期待されます。データヘルスレポートは、解析システムに取り込まれるデータが数値レシピを実行するのに十分な質であるかどうかを判断する、全社的な評価のようなものです。その結果は、数値レシピの実行を承認するか、あるいは問題があるとして反対するという二者択一の判断となります。次回の講義で詳しく説明するデータインスペクターは、提案されたサプライチェーンの決定について実務担当者が洞察を得るための入り口となります。
質問: 例えば、解析モデルを毎日更新して在庫方針を設定することは可能でしょうか？サプライチェーンシステムは毎日の方針変更に対応できず、システムにノイズを与えるだけではないでしょうか？
質問の前半に回答すると、解析モデルを毎日更新することは確かに可能です。例えば、2020年にLokadがヨーロッパでロックダウンが実施されていた際、各国がわずか24時間前の通知で閉鎖や再開を余儀なくされました。このため、常に即時の改訂が求められる極めて混沌とした状況が生じました。Lokadはこの極限状態の下、ヨーロッパ全域で日々開始または終了するロックダウンの管理を、ほぼ14ヶ月にわたって行いました。
したがって、解析モデルを毎日更新することは可能ですが、必ずしも望ましいとは限りません。確かにサプライチェーンシステムには大きな慣性があり、適切な数値レシピはまずほとんどの決定におけるラチェット効果を考慮する必要があります。一旦生産を指示し、原材料が消費されれば、その生産を元に戻すことはできません。新たな決定を行う際には、すでに多くの決断がなされていることを考慮に入れなければなりません。しかし、サプライチェーンが劇的な変化を必要としていると判断したならば、単に決断を先延ばしにするためだけに修正を遅らせる意味はありません。変革を実施する最良の時期は、まさに今なのです。
質問のノイズに関する側面については、適切な数値レシピの設計にかかっています。不安定で間違った設計が多く存在し、データのわずかな変動が数値レシピの結果に大きな変化をもたらすことがあります。数値レシピは、サプライチェーンの小さな変動によってむやみに跳ね上がるべきではありません。これが、Lokadが予測において確率的な視点を採用した理由です。確率的視点を用いることで、平均を捉えようとして外れ値が発生するたびに不安定になりがちなモデルと比べ、はるかに安定したモデルの構築が可能となります。
質問: 非常に大きな企業におけるサプライチェーンの問題の一つは、異なるソースシステムへの依存関係です。これらのソースシステムからすべてのデータを統一されたシステムに集約するのは極めて困難ではないでしょうか？
すべてのデータを収集することが多くの企業にとって大きな課題であることには全く同意します。しかし、そもそもなぜそれが課題となるのかを問い直す必要があります。先に述べたように、現在大企業が運用する業務アプリケーションの99％は、主流でしっかりと設計されたトランザクションデータベースに依存しています。依然として、わずかに古いCOBOL実装が難解なバイナリストレージ上で動作している場合もありますが、それは稀なケースです。1990年代に導入されたシステムであっても、業務アプリケーションの大部分はバックエンドでクリーンな生産グレードのトランザクションデータベースを利用しています。
一度トランザクショナルなバックエンドが整えば、このデータをデータレイクへコピーするのがなぜ難しいのでしょうか？多くの場合、企業が直面する問題は、単にデータをコピーするだけでなく、その上で多くの処理をしようとする点にあります。データの準備や変換を試みるあまり、プロセスが過度に複雑化されてしまうのです。現代のほとんどのデータベースシステムには、トランザクションデータベースからセカンダリーデータベースへすべての変更を複製するための組み込みのデータミラーリング機能が備わっており、これは市場で最も頻繁に使用されるトップ20程度のトランザクションシステムの標準機能です。
企業がデータ統合に苦労するのは、やりすぎてしまい、その取り組みが複雑さゆえに崩壊してしまうからです。一度データが統合されると、IT、BI、またはデータサイエンスのチームがデータ接続を行うべきだと誤解しがちです。ここで伝えたいのは、マーケティング、営業、財務が各自の部門で数値レシピを管理するのと同様に、サプライチェーンも自らの数値レシピを掌握すべきだということです。それは、会社全体を横断する支援部門が行うべきものではありません。異なるシステム間のデータ接続には、通常、膨大なビジネス上の知見が必要となります。大企業が失敗するのは、本来その部門内で行うべき作業を、IT、BI、またはデータサイエンスの専門家に委ねようとするからです。
本日はお時間をいただき、またご興味とご質問を誠にありがとうございました。夏休み明けの9月に、またお会いしましょう。
