00:00:00 あなたが思っている以上に優れたデータ
00:03:43 なぜ「悪いデータ」がスケープゴートになるのか
00:07:26 取引事実 対 パラメーター・ジャンク
00:11:09 レポーティング層の「ケーキ」が意思決定を阻害する
00:14:52 意思決定を最優先にした有用な情報の見方
00:18:35 パラメーターの自動化：リードタイム、季節性、新しさ
00:22:18 ERPの複雑さは悪いデータではない
00:26:01 日付フィールドは複数の現実の意味を隠している
00:29:44 生成された意思決定によって証明されるセマンティクス
00:33:27 外れ値は悪いデータではなく悪い手法を露呈する
00:37:10 データレイクは“improve”するのではなく、コピーすべきである
00:40:53 データ品質はドルで測られる
00:44:36 AIレディネス：信頼できる取引、セマンティクス第一
00:48:19 二重運用は完全無人実行を要求する
00:52:02 ベンダーの責任転嫁ゲーム：Lidl-SAPの警告的事例
00:55:45 品質は意思決定への適合性に等しい
概要
“悪いデータ"はしばしばスケープゴートとなる。ほとんどの企業の取引記録―購入、販売、出荷、返品されたもの―は十分に良好である。そうでなければ存続しなかったはずだ。本当の混乱は、手動で管理されるパラメーターの山と、フィールドが実際に何を意味するのか（セマンティクス）に対する混乱にあり、特に広大なERPにおいて見られる。弱い手法を救うために現実を「クリーンアップ」しないでくれ。外れ値はしばしばビジネスそのものである。結果によってデータを評価せよ：もし意思決定が利益を改善するなら、データは十分であったことになり、もし成果が常軌を逸しているなら、解釈を修正すべきである。
詳細な概要
サプライチェーンでよく聞かれる不満は、「悪いデータ」が進展を阻むというものだ。しかし、悪いデータと呼ばれるものの多くは、実際には悪くもなく、問題の核心にもなっていない。これはしばしば都合の良い言い訳であり、時にはソフトウェアの不具合時に責任を他者に転嫁するため、また時には整然とした教室用データセットに慣れ親しんだアナリストが実際の企業システムの膨大さに衝撃を受けるためである。数千のテーブルを持つERPは悪いデータの証拠ではなく、複雑さの証拠である。
この議論は「データ」の2種類の間に明確な境界線を引く。第一は取引的現実、すなわち購入、販売、出荷、返品、廃棄、支払いといった財務的影響を伴うイベントである。この情報は通常信頼できる。なぜなら、基本的な取引の真実を維持できない企業は長続きしないからだ。市場はそのような混乱を迅速に罰する。エラーは存在するが、通常はごく低い割合である。
第二は、手動で管理されるパラメーターの山―サービスレベル目標、安全在庫係数、季節性フラグ、事務員によって入力されたリードタイムなどである。これらの「数値的人工物」は通常、陳腐で一貫性がなく、大規模に維持するにはコストがかかる（百万単位のSKUに対して複数のパラメーター）。しかし、重要な点は、それらがしばしば不要であるということである。多くの入力は、観測された履歴から推測されるべきか、より良い方法で自動化されるべきである。それらを「コアデータ」として扱うことは、自らに重荷を課すことになる。
大きな隠れた問題はセマンティクス、つまりフィールドが何を意味するのかである。同じカラムでも、時間の経過やビジネスプロセスの変化、あるいは符号（販売と返品）によって意味が変わることがある。ドキュメンテーションは通常、初期段階では乏しい。セマンティクスを検証する唯一の信頼できる方法は、無限のワークショップではなく、解釈を実際のテストにかけることである。すなわち、何を購入し、生産し、在庫し、価格設定するかという実際の意思決定を生成し、その結果が非常識にならないかを確認する。もしそうであれば、誤った仮定を探るためにパイプラインを逆解析するのだ。
これは「ノイジーデータ」の見方も再定義する。もし顧客が時には1個、時には100個注文するなら、それは悪いデータではなく、ビジネスそのものである。外れ値で崩壊する手法は欠陥がある。弱い数学的手法を救うためにデータを改ざんすべきではない。
最後に、「AIレディネス」についてだが、求められるのはデータの道徳的純粋さではなく、目的への適合性である。何を購入し、生産し、販売するかが分かっていれば、着手できる。本当の仕事は、システムごとにセマンティクスをマッピングし、意思決定が合理的になるまで迅速に反復することである。結局のところ、品質は単なるスローガンではなく、意思決定の経済的成果によって測定される。
全文書き起こし
Conor Doherty: こちらはSupply Chain Breakdownです。本日は、なぜあなたのデータが実際にはあなたが思っている以上に優れているのかを徹底解説します。多くの企業は、自社のデータが望むプロジェクトの開始を阻む要因であると言います。しかし、今日はその考えに異議を唱えるために参りました。建設的に議論を進めましょう。
私たちは誰なのか？ 私はLokadのマーケティングディレクター、Conorです。左側には、いつも通りLokadの創設者であるJoannes Vermorelがいます。さて、始める前に下のコメント欄で教えてください。第一に、あなたは世界のどこから私たちを見ていますか？ 私たちはパリにいます。第二に、マスターデータが実際に今日の企業が取り組みたいと考えるデジタルトランスフォーメーションプロジェクトのボトルネックであるということに賛同しますか、あるいはそう考えますか？ コメントや質問をお寄せください。後ほど取り上げます。
それでは、Joannes、議論に入ってください。さて、本題に入る前に少し背景を説明しましょう。この議論がどのようにして始まったのか。ご存知の通り、各エピソードの最後に私は「もし議論を続けたいなら、Joannesと私に個別に連絡してください。喜んでお話します」と言います。どれも事実です。実際、そうする人もいます。彼らは話したいのです。
そして最近、私たちは個人としても集合的にも議論を重ね、その中で実務者たちはデータの現状について嘆く傾向がある。例えば、「私のマスターデータはスパゲッティのようだ」、「私のERPはスイスチーズだ」など。しかし、これこそが問題であり、私がやりたいクールなことを阻む要因となっているのです。これが本日のテーマに至った理由です。
では、Joannes、なぜサプライチェーンにおいてデータはそんなに悪い評判を受けるのでしょうか？
Joannes Vermorel: 聴衆によって理由はいくつか考えられます。
ソフトウェアベンダーにとって、悪いデータは究極のスケープゴートです。これは、ソフトウェア製品の何らかの欠陥について、丁重ながらも断固としてクライアントに責任を転嫁する方法なのです。そのため非常に都合が良く、優秀な才能あるベンダーは、もし全体が崩壊したなら、データ管理の慣行や品質保証が不十分だったことをクライアントの責任と納得させるのです。
しかし私の見解では、それは単なるスケープゴーティングに過ぎません。第二の対象はデータサイエンティスト、特にKaggleコンペティションで実績のあるデータサイエンティストです。彼らは、特に大学で、非常に整然としたデータセットに慣れており、それが標準だと考えています。つまり、5つのテーブルがあり、各テーブルに5つのフィールドがあり、すべてのフィールドについて詳細なドキュメントが整備されているデータセットがあれば、それが理想だと思っているのです。私にとってこれは、極めて非現実的な期待の問題です。
企業、つまり中堅市場向けのERPを例に取れば、1万ものテーブルがあり、中には50のフィールドを持つものもあります。これが現実です。したがって、データサイエンティストが企業データに対して全く不合理な期待を抱いているという問題に直面しているのです。
そして第三のセグメントは実務者です。彼らが注目しているのは、通常、自社システムのパラメーター化です。すなわち、特定の日付に、特定の価格で販売されたユニットのような実際の事象ではありません。これは通常、彼らの関心事ではなく、過去の主要な取引イベントに関するものではありません。
彼らが注目しているのは、「ああ、しかし見てください、2年前にAPSに入力した季節性設定が、今ではあれこれの理由で全くずれている」とか、「見てください、安全在庫の計算用の補正係数が山ほどあり、こちらも全くずれている」といったことです。実際、実務者が悪いデータと嘆く場合、彼らは非常に具体的に数値的人工物―すなわち、過去や未来を表さないもの―について不平を述べているのです。これらは企業の方針のパラメーター化の一形態を示しています。
私の見解はこうです。最初のケース、すなわちソフトウェアベンダーに戻ると、もしあなたが使用しているソリューションが手動で管理されるこのパラメーター化に極端に依存しているなら、必ず問題に直面することになる。したがって、唯一の解決策は、これらを現状のまま扱うのをやめることにある。これらをそもそも全体像に含めるべきではなく、対処する必要さえなくすべきなのです。
Conor Doherty: もし私の理解が間違っていなければ、あなたがおっしゃるのは、データには大きく分けて2つのカテゴリーがあるということですね。つまり、人々が「データ」という用語を使うとき、本質的に2種類のものを念頭に置いているということです。一つは、いわゆる数値的人工物、つまり彼ら自身が設定した特定の目標などであり、もう一つは実際の生の取引データであり、後者の方がはるかに重要だと考えているわけです。
Joannes Vermorel: ええ。つまり、本当の取引データとは、実際に起こった事実です。重ねて言えば、売れたかどうか、仕入先に支払ったか、注文を通過させたか、在庫からユニットをピックしたか、実際に傷みやすい商品の賞味期限を過ぎて破棄したか、などなど。これらは全て取引に関するものであり、通常は非常に優れています。
しかし、多くのビジネスソリューションでは、システムを単に操作する事務員によって管理されるべきパラメーターの山も存在します。そして疑問は、なぜこれほど膨大なパラメーターが必要とされるのかということです。というのも、話しているのは非常に大量のパラメーターのことだからです。
規模感を示すために例を挙げると、例えば100万のSKUを持つ企業の場合、実際はそれほど大きくないかもしれませんが、仮にSKUあたり10のパラメーターがあるとすれば（私としては控えめな見積もりで、実際はもっと多いかもしれません）、つまり約1000万のパラメーターをほぼ手作業で管理しなければならないことになり、これはまさに非常識です。
その上、人々は「これでは管理できないからクソだ」と言います。私としては、まさにその通りだと思います。しかし実際には、そんなものは本当に必要ではありません。そして、それらは実際のところ、情報を正確に伝えているわけではありません。なぜなら、それらのパラメーターは結局、他のデータを参考にして設定されたものだからです。
例えば、人々がサービスレベルの目標を設定する際、取引履歴を見て決定するのです。ご覧の通り、この情報は実際には完全に一時的なものであり、コアデータの一部とみなすべきではありません。だからこそ、悪いデータという問題は、人々が期待するよりもずっと小さいのです。彼らが本来データとして扱うべきではないものを、大部分データとして扱っているだけなのです。
もう一つの観点もありますが、これは別の問題です。これは、特にレポート層から得られる前処理済みデータに基づいてさらに分析を行おうとする場合に起こります。
改めて申し上げますが、私はエンタープライズソフトウェアを3つのクラスに分類しています。記録システム―これは計画を除いたERP（計画が含まれないため）―、レポートシステム、すなわちビジネスインテリジェンスやダッシュボード、報告のためのシステム、そして意思決定を行うインテリジェンスシステムです。
データの唯一の真実の源は記録システムにあります。しかし、多くの場合、人々は誤った認識に陥っていたり、忙しかったりするため、レポートシステムから提示されるそのままのデータを利用しようとする。そして、その結果、あたかも料理人のような状況に陥ってしまうのです。
例えば、あなたがキッチンを持ち、すべての生の食材―小麦粉、砂糖、塩―が揃っていると想像してください。それが記録システム、すなわち生の素材です。そして、料理人はレポートシステムを通じてケーキを作ることができます。出来上がったケーキは素晴らしく、人が消費できる状態になっています。
しかし今、あなたは料理人に「このケーキを使って何か他のことをしろ」と要求します。そして、これこそが、例えば意思決定プロセスを推進するためにレポート層からのデータを利用しようとする際に起こる事態です。それは非常に悪い結果を招きます。料理人が下手なわけではなく、既に完成したケーキからはそれ以上のものは得られないのです。本来の素材である砂糖や小麦粉などを分離しようとすると、すべてが失われてしまいます。
したがって、何か別のことを行いたいのであれば、生の素材、つまり基礎データに立ち返る必要があるのです。これが、多くの企業が犯す典型的な誤りでもあります。彼らは、人間の消費向けに設計されたレポート層のデータを見て、それを抽出し、他の目的のために再処理しようとするのです。それは誤りです。生の素材に立ち返るべきなのです。
Conor Doherty: さて、改めて、生の素材、つまり基礎データに立ち返るという考えについてですが、私自身も…出所についてはどう考えるか自由ですが、これは単に背景情報として、我々が単なる憶測に留まっていないことを示すためです。
現在、Gartnerのレポートを参照しており、数百の非常に大きな企業を調査した結果、大半の企業がデータ品質を一貫して測定していないことが確認されています。実際には、我々のデータが悪いという感覚はあるものの、それが必ずしも客観的に測定された事実ではないのです。
ですから、ここで2つの疑問が生じます。ひとつは、それが全体としてあなたを驚かせるかどうか。そしてもうひとつは、人々がどのようにして迅速に自社データの健全性を診断できるかということです。
Joannes Vermorel: まず、取引データを見ると答えは簡単です。あなたの企業が利益を上げていれば、データは高品質であるに違いありません。なぜなら、何を購入し、販売し、生産しているかを知らない企業が存続した例を私は一度も見たことがないからです。
もしそれすら把握していなければ、あなたは光の速さで破産するでしょう。仕入先が送ってきた品目が分からなければ、重複して請求されることになるでしょう。顧客が実際に何を購入したのか分からなければ、正しく請求できないのです。市場は迅速に反応します。まさにダーウィン主義が働いており、市場は容赦なくそうした企業を淘汰するのです。
だから経験則として、誤った経営で破産の瀬戸際にない企業に所属している場合、取引履歴はほぼ間違いなく非常に高品質であると言えます。そう、千行に一度くらいの事務的なエラーが混じることはあっても—これはほとんどの企業で見られるオーダーの桁数です。あなたの場合、事務エラーはたとえば0.1％から時には0.5％程度であり、非常に非常に低いのです。多くの企業ではさらにそれ以下です。
さて、もしすべてのオプショナルなデータ、たとえばSKUの目標サービスレベルを決定できるパラメータ設定をシステムに持っている場合について話すとしましょう—ここで高品質なデータというのは一体どういう意味でしょうか？これはナンセンスです。
もし私が反対の立場を取るとしたら、このパラメータが存在する場合に、企業の在庫投資による収益率を最大化することにどれほど近いかを検証すべきでしょう。しかし、私たちは決してそんなことはしません。あまりにも複雑すぎるのです。もし実際にあなたがサプライチェーンが収益率を最大化すべきだという考えを採用するなら素晴らしいですが、そうでなければ、非経済的なアプローチは非常に速やかに排除されるでしょう。
要するに、このパラメータ設定においては、確かに大量のゴミデータが混じる傾向があります。しかし現実には、たとえば在庫プランナーが推奨される補充を見ても意味が分からないかもしれませんが、同じプランナーが直近の履歴や他のいくつかの情報を見ることで、1分以内に「よし、50ユニット注文しよう」と判断し、次のSKUに移るのです。
ですから、もしこのパラメータ設定データに基づいてロボット化、または自動化を試みるなら、データの品質は非常に非常に低いといえます。しかし、唯一の解決策は、ソフトウェアシステムをこのパラメータ設定に依存しない知能システムと捉え、これはあくまでワークフロー中心のプロセスを支援する機能に過ぎないと考えることです。
Conor Doherty: まあ、その点について追記しておこうと思います。なぜなら、可能な限り建設的な考えを強調するのが好きだからです。
我々の見解は、我々のことを追っている誰もがよく知っている通り、データの目的、ひいては会社で働く目的は、より良い意思決定、つまり実際により多くのお金を生み出す意思決定を下すことにあるということです。あなたは、より良い意思決定はレポートシステムの中にあるのではなく、すでに取引データそのものにあるという点を述べました。
つまり、本質的には、人々がより良い意思決定を下すためには—「より良い」の定義はあなたが望むように定義しても構いませんが、我々の場合は収益率の最大化を意味しますが—すでに取引データがあれば、積極的な意思決定が可能になるのです。
Joannes Vermorel: Lokadのほぼ全ての顧客に共通して気づいたことですが—我々が扱う年間200億以上の商品の流れを操縦しているという事実もあって—情報の99%が、実際にはその質量の99.99%が取引システムから来ています。
さらに、手動で管理しなければならない数十個のメタパラメータ、つまり経済的なドライバーがあるかもしれません。しかし、ここでは非常に慎重になる必要があり、実際のところごく数十個に過ぎません。したがって、ここでのデータ品質は高くなければならないのです。難しい作業ですが、非常に少数の重要なパラメータ、すなわちパラメータごとに何度も会議に値するほど重要なものについて話しているのです。
しかし最終的には、それはSKUレベルのものではなく、戦略的で経済的、そしてハイレベルなパラメータでなければなりません。すべては完全にロボット化される必要があり、実際に可能です。
だからこそ、データは通常、素晴らしいものだと言えるのです。必要なのは取引履歴であり、問題に正しく取り組めば、何百万もの手動管理が必要なパラメータをシステムに入れておく必要はなく、しかも多様な形態を持つ必要もありません。
多くのシステムは操作者にリードタイムを入力させようとします。しかし、なぜリードタイムを入力する必要があるのでしょうか？サプライヤーからそのリードタイムを観察すればよいのです。つまり、リードタイムはユーザーが入力するものではなく、予測されるべきなのです。
また、多くのシステムはユーザーに分類して、「これは季節商品ですか？」といった判断を求めます。なぜ、製品ラベルだけがあれば完全に自動化されるべきこれらの作業を手動で行う必要があるのでしょうか？今日では、大規模言語モデル(LLM)のおかげで、この種の検出作業を自動化するのはかつてないほど容易になっています。「新商品があるのですが、これは季節的なパターンを示すだろうか？」といった具合です。非常に明快です。
人が介入して「おお、スキー用品の組み合わせですね。ああ、これは季節商品になるでしょう。分かりました、ありがとう」と言う必要はありません。現実はこうです：これらは非常に基本的な疑問であり、すべてのシステムが操作者にあまりにも多くの、明らかに自動化可能な入力を要求しているのです。
時には非常に不可解なことさえあります：操作者はこれが新商品であるかどうかを手動で入力しなければなりません。なぜシステムに新商品であると伝えるために人が必要なのでしょうか？履歴を見れば、それに該当する取引がなかったはずです。商品は最近システムに作成され、取引はゼロ—それなのに手動で新商品と設定する必要があるとは、全くのナンセンスです。
しかし改めて言えば、この分野、つまりすべてのポリシーに対するパラメータ設定におけるゴミデータは、サプライチェーンを捉える旧態依然とした方法を反映しているに過ぎません。だから、この面でどんな悪いデータがあっても、それは無意味です。大事なのは取引データであり、この取引データは良質で、会社が存続している証でもあるのです。
Conor Doherty: さて、その点についてですが、また、この認識の原因をもう少し深く掘り下げてみたいと思います。単に「問題がある」と言うだけでは不十分で、「では、その原因は何か？根本は何か？」という問いかけが必要なのです。
ですから、あなたの話を聞くと、そうですね…具体例を一つ挙げ、それについて議論できればと思います。私も聞いたことがありますし、あなたも聞いたことがあるでしょうが、「私のERPはめちゃくちゃだ」という話です。そしてそれは、取引データの記録システム、すなわち取引履歴の書物についての話であり、「重複したテーブルがある、誤ってラベル付けされた列がある、全くめちゃくちゃだ」と言われるのです。
技術的には、すべての取引データ、生の取引データは存在しています。問題があるとすれば—これについて議論は可能ですが—つまり、あなたが実施したERPの移行が混乱を招いたという点です。そして、ここで明言しておくと、我々はERPを販売しているわけではなく、どんなシステムでも対応できるので、その件に関しては一切関与していません。
しかし私の質問はこうです：ここでの悪いデータの流行において、ソフトウェアの選択がどれほど大きな役割を果たしているのでしょうか？
Joannes Vermorel: ここでもう一度言いますが、それは誤った期待から来るものです。これこそが、第二の対象層、つまりデータサイエンティストやKaggleコンペティションの話をしたときの状況そのものです。ERP、すなわち記録システムが整然としているとは断言しなかったのです。複雑さは桁外れになり、それで全く問題はないということです。
これは悪いデータではありません。ただ、非常に複雑で非常に不透明なデータ、つまり別の問題なのです。確かに、テーブルが1万ある場合、在庫レベルがどこにあるかを特定するのは非常に困難です。困難であり、データがシステム内のどこに存在するかを追跡するのに数週間かかることもあります。しかし、これも悪いデータとは言えません。
さらに、別の問題として、任意のデータ列の意味論が一様でない（異質である）可能性があります。つまり、同じ列であっても、行ごとに意味が変わる可能性があるということです。これが複雑な点なのです。
たとえば、かつてある迷走したERPベンダーは、注文テーブルにおいて、数量が正の場合はそれが販売、すなわち顧客への販売を意味し、その日付を販売の取引日としたのに対し、数量が負の場合は返品を意味し、商品の返品日としたのです。つまり、「注文日」と呼ばれる列があるものの、数量が負の場合は注文日ではなく、実際には返品日となるのです。
これが私の言いたいことです：同じ列でも、行や条件によって意味が異なり、場合によっては、例えばERPがアップグレードされ、2020年1月1日以降、注文日の意味が変更されたなどの事態が起こるのです。システムのアップグレードによって、意味論が時とともに変わってしまったのです。
場合によっては、会社内の各チームがプロセスを変更し、特定のフィールドの意味論を再定義し、新たな意味を持たせることすらあります。ですから、これは非常に複雑であり、その真相を解明するのも大変なのです。
しかし改めて問いますが、これは悪いデータなのでしょうか？もし、あなたが知っているERPベンダーが、ソフトウェア設計において多少無能であったために、「注文日」が販売の日付にも返品の日付にもなりうると決定したとしても—それは誤った判断ですが—悪いデータと断じることはできません。データ自体は良好で、ただ意味論が混乱しているだけなのです。
我々は、意味論の再構築が非常に大変な作業であるという事実に立ち返ります。私もそれには同意します。しかし、人々が「悪いデータ」と言うとき、私が非常に頻繁に言うのは、「いいえ、あなたのデータは全く問題ありません。ただ、実際の意味論を再確立するための作業を本気で行う必要があるだけです」ということです。
経験則として、クライアントとのプロジェクト開始時には、テーブルごとやフィールドごとに一行のドキュメンテーションすら存在しません。しかし、プロジェクトが完了すると、Lokadの取り組みに実際に関連するフィールドについては、各テーブルごとに1ページのドキュメントが作成されるようになります。それが供給チェーン管理の定義なのです。
それにもかかわらず、20のテーブル、20のフィールド、つまり400ページ分のドキュメンテーションになるのです。これはITドキュメントではなく、サプライチェーンのドキュメントです。なぜなら、各フィールドがサプライチェーンの観点からどのような意味と含意を持つのかという意味論を明確にする必要があるからです。ですから、非常に大変な作業なのです。
改めて思うのは、「悪いデータ」というスケープゴートの下で、多くの人々がこの意味論の明確化にどれだけの労力が必要かを理解していないということです。その上、無能なソフトウェアベンダーがそれを喜んで言い訳に使い、「それはあなたの責任です」と客に告げるというのです。
Conor Doherty: さて、その点についてですが、実は…これをやるとはあなたは予想していなかったでしょうが、明らかにあなたの新しい本も出ています。しかし、その準備のために、実はあなたの古い本に戻って見たのです。
そして、既にJoannesの両著を読んでいるOGの皆さんは、今すぐにでも自分のコピーを取り出すことができます。当然、この本の最後の数百ページにあるコードは今日ではそれほど関連性がないかもしれませんが、最初の…最初の100ページは今なお非常に非常に重要です。
そして、手元に本がある方へ：60ページ、意味論に関するトピックについて—これが単なる抽象的な哲学ではなく、非常に具体的な例を示し、具体的な質問をするためのものだということを示すためです—少しだけ読み上げさせていただきます。非常に啓発的だと感じたので。
ここ、60ページではこう書かれています：特定の日付に関連する1日あたりの数量について言及する場合、その日付自体には固有の曖昧さが伴います。それは、顧客が注文を行った日、顧客が予約注文を確定した日、製品が顧客に出荷された日、ERPに注文が到着した日、ERP内で最後に注文が修正された日、または顧客からの支払いが最終的に受領された日などを意味するかもしれません。そして、保証期間や返品期間が終了した日とも解釈できるのです。
これらはすべて、単純な日付に対する具体的な意味論的解釈です。
Joannes Vermorel: ええ。単純な日付についてです。
Conor Doherty: まさにその通りです。しかし、私の言いたいのは、もしその中のどれか一つを選んだ場合、どれほどのダメージが生じるのでしょうか？まるで意思決定ツリーのように、突然下す意思決定が大きく異なってしまうのでしょうか？その規模について、なぜそうなるのか説明していただけますか？そうすれば皆理解できるはずです。
Joannes Vermorel: はい。意味論において誤った解釈をすると、その誤りを確実に知る唯一の方法は、最終的なパイプラインの終点で非常識な意思決定が発生することにあるのです。
完全に自動化されたパイプライン、すなわちサプライチェーンのリソース配分—何を購入し、何を生産し、どこに在庫を置き、売るすべての記事の価格設定を行う—を生成する完全無人のデータ抽出パイプライン、すなわち数値的なレシピが存在しない限り、あなたは自分の意味論を評価し、検証するために必要な手段を欠いているのです。
もし、あなたのドキュメントに誤って記載され、例えばその注文日を支払いが完了した日だと思い込んでいたとしましょう。実際にはそうではなく、商品を顧客に出荷する準備が整った日付であった場合—つまりドキュメントが間違っているのです—あなたはそれに気づくことができないでしょう。誰も気づくことはできません。
おそらく、2日間かけてそのフィールドを徹底的に調査すれば、修正することができるかもしれません。しかし、そもそも最初に間違いがあったことに気づかなければなりません。たとえ小規模なイニシアチブであっても、何百ものフィールドが存在します。各フィールドごとに数日間のワークショップを行い、意味論を正確にするつもりでしょうか？それは現実的ではありません。
ですから、合理的なアプローチは、最善の努力、最良の推測をして、その解釈に基づいて意思決定を生成し、そして時折、非常識な意思決定が生じるという仕組みにすることです。私たちはイニシアチブ開始時に、非常に多くの全く非常識な意思決定を生成します。
そして、その後、皆で確認し、「ああ、この数字はおかしい」と言います。そこで、なぜその非常識な意思決定に至ったのかを逆算し、さかのぼって検証するのです。そのための計測手段が必要です。
最終的に、「ああ、この日付は…ああ、我々は誤解していた」と結論付けるでしょう。実際、この状況で適用されるリードタイムは、日付の解釈を誤っていたために全く異なるものとなるのです。では、修正された解釈で意思決定を再生成してみましょう。ああ、今度はずっと合理的に見えます。よし、次に進みましょう。
本質的には、あなたの意味論が正しいかどうかを評価する唯一の方法は、実世界でテストすること、すなわち意思決定を生成して実務家に「これは理にかなっているか？」と問い、もしそうでなければ再検証するということです。
多くの代替ツールが犯す過ちとして、生成されたデータがナンセンスな場合に「パラメータを微調整すればいい」と言うものがあります。しかし私が言いたいのは、パラメータが問題の根本原因とみなされる場合に限り、微調整が必要であり、そうでなければそれは解決策ではないということです。
とても非常に頻繁に、問題が発生します… セマンティクスの重要性を強調してもしきれません。本当に非常に繊細な問題です。唯一の方法は生成された意思決定を確認することであり、これはさらに問題を複雑にします。なぜなら、計画分野の多くのツールは最終的な意思決定を生成しないため、その結果、ソフトウェアベンダー自身が正しいセマンティクスを評価する手段を失ってしまうからです。
Conor Doherty: そうだ。さて、改めて君が指摘した点に橋渡しする話として、データという概念——私たちは意思決定を下すためにデータを利用する。確率的予測を使うかどうかにかかわらず、それがLokadのアプローチで提唱される考え方だ。しかし、根本的には、データは少なくともひとつのステップ、つまり予測を促進し、その後で意思決定に至るプロセスを補助するために用いられる。
しかし、実務者からよく聞かれるのは、「データに多くのノイズがある」という点です。予測の文脈では、ノイズの多いデータは本当に問題なのでしょうか？
Joannes Vermorel: 絶対にそうではありません。たとえば、あなたのビジネスが不規則で、顧客が時には1つ、時には100を注文するのであれば、それがあなたのビジネスの現実なのです。
多くのサプライチェーン手法、すなわち数値的手法は極めて欠陥があります。統計的な外れ値に直面すると、数値的にはその手法が正しく動作せず、外れ値が発生すると、手法が完全に狂い、全く意味不明な結果を生むのです。
その後、人々は「過去のデータを修正して外れ値を除去しなければならない」と言います。「その外れ値は悪いもので、不調の症状だ」と。しかし私は全くそうは思いません。もし顧客が実際に過去に100単位注文していたのなら、それはたとえ外れ値であっても、それが現実なのです。実際に起こったのです。
もちろん、システム内に百万単位の注文記録があるのに、実際にはそのような注文がなかった場合は、それは不正確なデータです。ここで重要なのは、トランザクションデータ、すなわち取引の記録は正確であるという点です。
しかし、もし数値的手法が過去の外れ値に直面し、途方もない結果を出すのであれば、問題はデータではなく手法そのものが劣悪であることに他なりません。不良な手法に直面しているのです。より数値的に正しく動作する方法を採用すべきです。これが本質なのです。
これは典型的な状況で、データ自体は完璧であるにもかかわらず、極めて欠陥のある手法を提案するベンダーが、自らの顧客に対して、実はデータは悪いから手動で修正すべきだと納得させるというものです。しかし実際には、データは全く問題なく、欠陥は数値的なレシピそのものにあるのです。
Conor Doherty: これは実際、切り替えの絶好の機会だ。実はプライベートで2件届いており、すみません、ちょっと整理して質問としてまとめさせてください。
さて、実務者からの質問です。「我々はすでにデータレイクを構築し、明らかにカタログも持っていますが、エンドユーザーからはデータが間違っていると言われます。あなたの意見では、ボトルネックは技術にあるのか、それともセマンティクスにあるのか？ そして、JoannesやLokadはどのようにして果てしない再ラベリングを回避しているのか？」
なぜなら、先ほどあなたがセマンティクスとその重要性について多く語ったからです。これは、いかにデータレイクを構築するかに依存します。あなたのデータレイクは、システム・オブ・レコード内の記録の完全な1対1のコピーなのでしょうか？ つまり、前処理も改良も結合もフィルターも一切行わない、文字通り1対1のコピーなのでしょうか？ERPからのライブコピーではなく、多少の遅延があっても、コピー先は実際のデータそのままのものです。
Joannes Vermorel: それについて人々が不満を述べると、またもやデータサイエンティストにありがちな第二の問題に戻ります。「ああ、データが整然としていない。Kaggleの実験のようではないから混乱している」と。私が言うには、残念ながらこれがあなたの住む世界なのです。あなたのビジネスシステムが抱える情報は非常に複雑で、逃れることはできません。代替案は存在しません。
だから文句を言うかもしれませんが、それは重力に文句を言うようなもので、ただ事実として受け入れるしかないのです。
ごく頻繁にあるのは、私が理想として述べたデータレイクの状況、つまり各ビジネスシステムのバニラなレプリカではなく、ただのコピーであるという現実です。そして、「ただのコピーならなぜデータレイクが必要なのか？」と問われます。短い答えは、ERPや取引システムに過大な負荷をかけたくないからです。取引システムは非常に迅速に動作する必要があるのです。
例えば、「過去5年間の全販売注文を、すべてダンプしてくれ」という問い合わせがあれば、システム全体が遅くなってしまいます。大量のデータ抽出クエリによってリソースが枯渇し、他の業務に支障をきたすためです。だからこそ、レプリカを作成し、その大量クエリはプライマリシステムではなく、レプリカ上で実行するのがベストプラクティスなのです。
元の論点に戻りますが、多くのデータレイクではITチームが大きな過ちを犯します。彼らはオリジナルのデータを再処理し、改善しようと試みます。
しかし、ここでの落とし穴は、彼らが意思決定を生成していないため、正しいセマンティクスを把握できず、その結果、データに適用する変換が必ず誤った方向へ導かれ、期待するデータや必要なデータが得られず、修正不能な状態になってしまうのです。
どんなに有能で、どんなに献身的であっても、あの常軌を逸した意思決定を逆算するという極めて重要な手段に欠けているのです。そもそも、ITの役割はビジネスの意思決定を生成することではありません。ITは配管作業、つまりデータベースの設定、インスタンスのセキュリティ確保、十分なRAM、ディスク帯域、インフラの整備などを担当するだけなのです。
しかし、セマンティクスを求めるのであれば、ITはその分野に関与すべきではありません。セマンティクスは各業界に特有のものであり、ITが会計、マーケティング、サプライチェーン管理、法務などすべての専門家の代わりをすることは不可能だからです。だからこそ、セマンティクスは実務者の手に委ねられるべきであり、ITにその戦いを強いるべきではないのです。
Conor Doherty: さて、これまでに受けたコメントが2件あります。どちらも個人的に電話やミーティングですでにいただいており、その中から最も適切なものをフォローアップしようと思います。
私は、ITとオペレーションの間の対立の考えに基づいて話を広げてみたいと思います。実際のコメントは、「ITは我々のデータがひどいと言うが、実際にそれを使うオペレーション、つまり実務者は問題ないと言っている」というものであり、先ほどあなたが指摘したように、もし意思決定を行い利益を上げているなら、ビジネスにとっては問題ないということです。
そこで質問です。どのようにして我々は客観的に品質を評価し、何を今直すべきか、後回しにすべきか、あるいはそのまま展開すべきかを判断するのでしょうか？
Joannes Vermorel: 生成された意思決定の収益率で判断します。もし、データが一見クソであっても、生成された意思決定が良好であれば、それは本当にクソなのでしょうか？ もしかすると全く無関係なものかもしれません。私たちはそれを重要視しないのです。
もし、根本的に重要性の低いデータであれば、その正確さの有無は問題になりません。だからこそ、私たちLokadではデータの品質をドルで評価します。つまり、このデータを改善することが、ケースに応じて何百万ドルもの効果を生むかどうかで判断するのです。
もしこのデータを改善することで、より良い意思決定により年間で数百万ドルの利益をもたらすのなら、それは最優先事項です。おそらく投資すべきでしょう。しかし、このデータがさらに悪化しても影響がなければ、我々は気にしないのです。
だから私は言うのです。データの品質を評価する唯一の方法は、最終的にあなたのビジネスが生み出す意思決定に基づいているという点にあります。すなわち、そのデータが「クソ」かどうかは、それによって生まれる意思決定次第なのです。
たとえば、航空宇宙の分野でのフィールドを考えてみましょう。私たちは多数のフィールドを持っていますが、そのうちの1つは、全アイテムの99%について不完全であり、しばしば「コンポーネントのCナンバーはこの位置にある」といった注記が付されています。これは良いデータと言えるのでしょうか、それとも悪いデータなのでしょうか？
現実には、航空機部品のほとんどにおいては、Cナンバーの場所は非常に明確であり、注記すら必要ありません。ただ選べば明らかであり、読めば一目瞭然なのです。しかし、稀にそれが難解で、機械的な理由などから位置が分かりにくい場合もあり、そのときに小さな注記が役に立つのです。
ITの視点から見ると、「ああ、データ入力が一貫していない。見てください、このフィールドは全アイテムのたった0.5%にしか設定されていない」と言うかもしれません。しかし実際には、そうした僅かなアイテムが、実際に重要なケースなのです。
だからもう一度言いますが、データが良いか悪いかを評価する唯一の方法は、それを意思決定プロセスに適用してみることにあるのです。
Conor Doherty: さて、これで次のコメントに答えられるかもしれません。非常に特定の話ですが、現代では多くの人々がデータをAIに活用したがっており、AIプロジェクトなどを望んでいます。
ここでチャンネルの友人からの質問です：「我々は40以上の国を運営しています。複数のERPやWMSを用いて40か国の在庫管理を行っています。私たちのデータは、いつになればAIを開始するのに十分な状態になるのでしょうか？また、最初の90日、つまり最初の四半期に実際に何をするのですか？」
Joannes Vermorel: もし、あなたの国で何を購入し、何を生産し、何を販売しているかが明確であれば、AIの導入においては十分な状態であると言えます。それだけのことです。私たちにとっては、常にそうだったのです。したがって、ハードルはそれほど高くありません。
意思決定プロセスをロボット化するためのハードル、つまりあなたがAIと呼ぶかどうかは別として、その水準で十分であり、必要な条件を満たしています。これが私たちの実践していることです。だからこそ、人間が手作業で行うための微妙なワークフローのパラメータを維持する必要はなくなります。なぜなら、それらを使用しないからです。
根本的に、AIは従来の労働分業に挑戦します。予測担当、計画担当、予算管理担当、在庫管理担当、その他と続くワークフローは、AIの時代においては意味をなさなくなります。
AIは、システム・オブ・レコードから生のデータを取り込み、単一のモノリスとして直接意思決定を出力します。そして、その意思決定を支えるすべての計測装置を提供します。これが、なぜその意思決定が採られたのかを説明する経済的ドライバーとなるのです。完璧です。
あなたのAIシステム、あるいは私が呼ぶところの「知性システム」は、本質的には、記録を入力し、意思決定を出力するモノリスのようなものであり、そこに補助する計測装置が付随しているだけなのです。
人々が「我々には40のERPがある」と言ったとき、私は「実際に40という数は誰も保有していないのでは？」と言いたくなります。というのも、ある国で17のERPを保持していた企業を見たことがあるからです。それが記録保持者です。その企業名は伏せますが、非常に大きな企業で、同一国内での出来事でした。本当に信じがたい状況でした。
要するに、ERPごとにセマンティクスを再確立する作業を行わなければならなくなるでしょう。それは明らかに骨の折れる作業です。
彼は最初の90日について尋ねていましたが、通常、私たちがセマンティクスを確立するのにかかるのは2ヶ月です。これは、例えば国単位で稼働する一連のビジネスシステムに対して実施するものです。しかし、実際の境界は必ずしも国ではなく、どのITシステム（ERP、WMS、ECプラットフォームなど）を範囲に含めるかに大きく依存します。
我々のスコープはほぼ常にITシステムの境界によって決まります。なぜなら、その努力はセマンティクスを確立することに集中しているからです。そして、一旦セマンティクス、つまり最初のデータパイプラインが確立されれば、意思決定の改善を反復的に行い、通常それには約2ヶ月かかります。
つまり、データパイプラインを構築し、各フィールドのセマンティクスについて初歩的な見解を得るのに2ヶ月、そして最初の試行で誤ったセマンティクスを特定し、あらゆる狂気を排除するためにさらに2ヶ月の追加反復が必要なのです。
だから結局、90日間ではなく、例えば120日ほどかかるのです。狂気のない、実運用レベルの意思決定が得られるのです。これが典型的なLokadの取り組みです。
しかし要点は、データのセマンティクスに関する数多くの問題を特定するために、通常1日に複数回、迅速に反復できる必要があるということです。
Conor Doherty: さて、これはあなたが具体的な実装例を挙げたからなのですが、重要な点は、あなたの説明する実装が、いわゆる「デュアルラン」と呼ばれる現行のシステムと並行して動作するということです。実際に自分の目でその違いを確認できるのです。
Joannes Vermorel: その通りです。ここで全く手を加えず自動で動作するシステムが決定的に必要になるのです。なぜなら、並行して動作するデュアルランにおいて、第二のプロセスが大量の人手を要求するなら、その人手はどこから捻出されるのでしょうか？
例えば、ある会社に15人のプランナーがいたとしましょう。彼らは既に1日の業務を100%忙しくこなしています。もし100%忙しくなければ、その会社は12人や10人しかプランナーを抱えていないはずです。通常、特別な事情がない限り、企業には予備として何もしていない従業員が存在しないのです。
彼らはすでにその日に8時間の業務を行っており、別のシステムをちらっと見て外れ値や悪い、狂った意思決定をチェックするためにわずかに30分を捻出できるかもしれませんが、同じワークフローを8時間ずつ2つのシステムで行うことは不可能です。
だからこそ、この新しい意思決定システムは完全に無人で動作しなければならないのです。さもなければ、運用上、展開することは不可能になるでしょう。これはLokadが10年前に学んだ教訓です。
Conor Doherty: よし。さて、これまでに受けたコメントにはほぼすべて答えたと思いますし、あるいは「オンエアで質問してほしい」と明確に依頼されたコメントも尽きました。
建設的な締めくくりという観点で言えば、既に多くの点を網羅しました。例えば、来週―または任意の時間軸（ただし「1年」とは言わずに）、例えば今後30日間で、人々が実際に実行できる簡単な変更を導入することで、品質の向上はもちろん、少なくとも現状のデータの力に対する内部の認識を改善できるとしたら、どうお考えですか？
Joannes Vermorel: 短期間でできることがあるとは思いません。私にとって重要なのは、何を実際の主要な情報源として扱い、何を単なる数値上の産物として扱うべきかを認識することです。それは同じではありません。
この分離を行い、企業に対して財務的影響をもたらす真のイベントを示す実際のイベント駆動型データを客観的に見れば、おそらくそのデータが優れていることに気づくでしょう。確かに、混沌としている部分もありますが、本質的には優れているのです。ですから、これが問題ではありません。
私の伝えたいことは、10年以上デジタル化された企業における不良データは決して問題ではないということです。Lokadは過去15年以上で100件以上の実装を行ってきました。
時には、データ抽出があまりにも遅いシステムに関する問題がありました。そういった問題もありました。ちなみに、これがデータレイクを追加する理由です。なぜなら、時々「SELECT * FROM table X」といったクエリを実行した際に、システムが実際にメモリ不足の例外を起こしたからです。
つまり、データ抽出の際にシステムが崩壊して非常に複雑になる問題があったのです。これは実際の懸念事項です。皆さんがそのような状況に陥っていないことを心から願いますが、そういった場合もあり得ます。これがデータレイクを導入する理由です。
しかし、古いインフラに起因する非常に技術的な問題を除けば、本当に不良なデータは存在しませんでした。私たちが豊富に抱えていたのは非常に不透明で曖昧なデータでしたが、根本的にはそれはLokad側で解決すべき問題でした。
確かに、これは私たちにとって大きな問題でしたが、本質的にはクライアントの問題ではありませんでした。クライアントはただ自分たちのシステムを正しく使用していただけです。その結果、これを基に自動化された意思決定システムを実装しようとする場合、挑戦となります。しかし、挑戦はクライアントが最初にこのデータを収集したことを非難するのではなく、データを正しく解釈するところにあるのです。
Conor Doherty: もう1時間も続いていますので、マーケティングの観点から少しコメントしてもよいと思いますが、これは重要な核心部分です。
私自身が最近の多くの会話から学んだことの一つは、「ねえ、見てください、あなたのデータは現状でも十分良いですよ」という話をしているとき、人々には必ずしもその意味がはっきり伝わっていないということです。もしLokadや、場合によっては他の有能なベンダーと協力すれば、その負担は引き受けられるという認識を持たないのです。
つまり、あなたは彼らにデータを提供する、私たちにデータを提供するのです。あなたが処理する必要はありません。そして、彼らは…再び、もしベンダーが…
Joannes Vermorel: もしベンダーが自らその負担を引き受けなければ、それは責任転嫁の温床となります。
Conor Doherty: 全くその通りです。
Joannes Vermorel: ベンダーは単にあなたのせいにし、結果的に会社が7年間で5億を浪費するという状況に陥るでしょう。最終的に報告書は全てあなたのせいだと結論づけ、ベンダーは「いや、ここには何も問題はない。私のせいではない。さあ」といった感じになるのです。
ちなみに、Lidlのケースは非常に興味深いです。なぜなら、彼らは特定の点でデータが悪いと非難したからです。SAPは「おお、Lidlは購入価格を基に分析を行い、我々は販売価格を基に全ての分析を行っている。それが原因だ」と述べたのです。
私としては、皆さん、これは意味論の基本だと言いたいです。まず、問題としては些細なものです：販売価格なのか購入価格なのか？確かにここには意味論的な課題があります―どの価格について話しているのか。しかし、はっきり言っておきますが、非常に微妙な違いではありません。意味論的な区別としては、非常に容易に対処できるものです。
さらに、私には明らかに、両方の価格が必要だと考えます。マージンを把握するためには、購入価格と販売価格の両方が必要なのです。
したがって、ベンダーが7年後に「彼らは全サプライチェーンを購入価格を中心に組織している。私たちは販売価格を期待しているから、非常に複雑だ」とクライアントを非難するという考えは、まさにベンダーが適切な経済性能を伴う意思決定を提供することにコミットしていない場合に起こる典型的ないたずらです。
これが出発点でなければ、サプライチェーンの世界では多くの無意味な事態が発生します。結局、大金を費やした後、ベンダーは不良データを見つけ出すことであなたに責任を転嫁するのです。
再度申し上げますが、意思決定だけが重要であるという事実を受け入れなければ、全く無意味な膨大なデータが存在します。当然、そのような無意味なデータは極めて低品質である可能性がありますが、それで全く問題ありません。
ERPには10,000のテーブルがあります。各テーブルには数十のフィールドが含まれています。これらすべてのデータが整然としているべきでしょうか？それは狂気そのものです。なぜそんなことを望むのでしょうか？費用がかかりすぎるのです。
ですから、もしベンダーと「不良データ」のゲームをするなら、客観的に見てくだらないかつ無意味なテーブルやフィールドは常に存在するため、ベンダーが常に勝者となるでしょう。これが肝心なのです：無意味であるということ。
Conor Doherty: わかりました。結論としては、統合する際にはベンダーを慎重に選んでください。
Joannes Vermorel: その通りです。そして本当に理解していただきたいのは、ERPの品質と言ったとき、その意図は何かということです。目的は何か？会社にとって、道徳的な意味での純粋なERPなんてものは存在しません。ERPは目的にかなうためのものです。
品質とは、目的への適合性であり、それだけのことです。
Conor Doherty: 以上です。本当にありがとうございました。質問は尽きました。1時間も続きましたので、そろそろ時間のところでしょう。
いつものように、ご意見に感謝します。そして、参加してくださった皆さん、また個別にメッセージをくださった皆さんにも感謝いたします。最初に申し上げた通り、そしてこのテーマの由来でもあるのですが、もし会話を続けたい場合は、Joannesまたは私に個別にご連絡ください。いつでも喜んでお話しします。
先週も申し上げたように、そして毎週申し上げるのですが、私たちは素晴らしい人々です。ほら、私たちを見てください。では、その話はここまでにして、来週お会いしましょう。来週のための特別なトピックがあるので、月曜日に発表いたします。では、そのままお仕事に戻りましょう。
